[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference clt::cma

Title:	DECthreads Conference

Moderator:	PTHRED::MARYSTEON

Created:	Mon May 14 1990
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	1553
Total number of notes:	9541

1526.0. "Segmentation fault at exc_push_ctx" by EDSCLU::WANG () Wed Apr 16 1997 13:05

    Hi,
    
    	A customer is trying to run a CPIC function cminit() in
    sub-process. But he got a segmentation fault at exc_push_ctx(). Would
    you please tell me what that means?
    
    
    Thanks,
    Danqing
    
    
    	The program like this:
    
            main ()
    
               if (fork())
                  exit (0);
    
               normal CPI-C sequence ....
    
    DBX output:
    -----------
    
Now attached to Process 12094:
    signal Segmentation fault at   [exc_push_ctx:729 ,0x3ff8102e470]        
    Source not available
    (dbx) where
    >  0 exc_push_ctx(0x11fffed58, 0x2000000000, 0x74696e692e,
    0x3ff805065c0, 0x3ff805065c0)
    ["../../../../../src/usr/ccs/lib/DECthreads/COMMON/exc_handling.c":729,
     0x3ff8102e470]
       1 pthread_once(0x30040066dd0, 0x3000003e190, 0x74656e762e366d76,
    0x6d6f632e6d62692e, 0xa29)
    ["../../../../../src/usr/ccs/lib/DECthreads/COMMON/cma_pthread.c"
    :2839, 0x3ff81035ef0]
       2 snalu62_allocate(resource = 0x14000b970, tp_id = (nil), status_vec
    = 0x11ffff6f8, local_lu_name = 0x14000b84c = "USDEC101.INTRALU1",
    partner_lu_name = 0x14000b864 = "USDEC101.INTRALU2", mode_name = 0x14000b83c = "MODELU62",
    tpn = 0x11ffff640, type = 4, return_control = 5, conversation_group_id = 0,
    sync_level = 9,
     security = 0x11ffff6d8, pip = (nil), wait_object = (nil), luwid =
    (nil), conver
    sation_correlator = (nil), server_info = 0x11ffff6a0)
    ["/usr/users/snagwy/sna5/s
    nalu62v3_eco06/aosf/lu62/src/lu62_allocate.c":399, 0x3000001e47c]
       3 cmallc(conversation_ID = 0x11ffff8d8 = "", return_code =
    0x11ffff8d0) ["/usr/users/snagwy/sna6/snalu62v3_x061/aosf/cpic/src/cpicemul.c":733,
    0x3ffbffe8df0]
       4 do_aping(argc = 3, argv = 0x11ffff968) ["aping.c":440,
    0x12000371c]
       5 main(argc = 3, argv = 0x11ffff968) ["aping.c":271, 0x12000330c]

T.R	Title	User	Personal Name	Date	Lines
1526.1		DCETHD::BUTENHOF	Dave Butenhof, DECthreads	`Wed Apr 16 1997 15:34`	10
	This is clearly some variety of Digital UNIX 3.x. You don't specify, and you should. I'm not about to go blindly through the various source pools looking for a line number that matches, so I can only answer in general. The code has called pthread_once, which calls out to a supplied routine in the client code. We don't "trust" it, so we declare an exception handler around it. The SEGV occurred in trying to do so, which means that the current thread context is corrupt. I cannot speculate on how it became corrupt. /dave
1526.2	How was the application built?	WTFN::SCALES	Despair is appropriate and inevitable.	`Wed Apr 16 1997 15:56`	6
	And, while you're posting additional information, please include the customer's compile/link command line so we can see how the application was built. Webb
1526.3		EDSCLU::WANG		`Thu Apr 17 1997 09:10`	36
	Hi, We reproduced the problem here and we are running D/U V3.2C. After we changed our makefile, the problem went away. But I don't really understand why? The following is the original makefile. ----------------------------------------------------------------------- # # Makefile for APPC programs # CC = c89 INCS = cpiccmc.h cpicdefs.h cpicerr.h cpicinit.h cpicport.h CFLAGS = -c -std1 -g -I/usr/include/sna \ -DSNALOG_ENABLED -D_REENTRANT -DOSF LIBLIST = -L/usr/shlib -lcpic -lc LINK_OPTIONS = -g everything: aping aping: aping.o cpicerr.o cpicinit.o cpicport.o cc -o aping aping.o cpicerr.o cpicinit.o cpicport.o\ $(LINK_OPTIONS) $(LIBLIST) ----------------------------------------------------------------------- We changed LIBLIST from "-L/usr/shlib -lcpic -lc" to "-lcpic -threads" then the program runs fine. The question is why the program cannot link with shared objects? Thanks for your help.
1526.4		DCETHD::BUTENHOF	Dave Butenhof, DECthreads	`Thu Apr 17 1997 10:33`	16
	There are many things on 3.x that don't work without all the right libraries loaded in the right order. Yes, if you're using shared libraries, all the "others" will be pulled in by dependencies -- but they're in the wrong order. In particular, libpthreads.so, libmach.so, and libc_r.so all PREEMPT symbols from libc.so -- so if libc.so is loaded first (which it will be unless you ask for the others, in the correct order), the process is busted. Using -threads specifies all the libraries in the proper order. That's also (part of) why a nonthreaded program cannot successfully dlopen a shared library that uses threads -- again, the other libraries will be loaded AFTER libc, and cannot preempt its symbols. Digital UNIX 4.0 doesn't rely on preempting libc symbols -- with one minor exception in libexc, which I'm still hoping will be fixed. /dave