RE: A couple of small problems

Thanks for the prompt response. FYI: I'm running an unmodified (with the
exception of the NGPT patch) 2.4.19 kernel on top of a Redhat 8.0 install.
Although it is a strictly in-house application that I'm running and it is only
used by developers, running on a development kernel is not an option, pretty 
much restricting me to 2.4.18, 2.4.19, or 2.4.20.
 
1) Thanks.

2) I checked the core file size, the default was unlimited, but just for kicks I
tried setting it to 200000 and ran the modified test program again. The results
are below. Segmentation faults do cause core dumps. 

Another data point, I just wrote a test program that does little more than call
abort. The a.out from "gcc test.c" dumps core, the a.out from 
"gcc -lpthread test.c" dumps core, but when I add in a call to
pthread_create(&tid, NULL, printf, "foo"); to force the library to be loaded, it
no longer dumps core. 

3) Is the most recent patch for the 2.4.x the one from July 18th? I'll try that, 
that might meet my needs as I can get away with all my threads being
SYSTEM_SCOPE.

hershey% ../test_str01 
Allocating 85 nodes.
Creating root thread attributes via pthread_attr_init.
Creating root thread via pthread_create.
thread 0 creating kids, cdepth=1
thread 1 started
thread 2 started
thread 3 started
thread 4 started
Aborted
hershey% ../test_str01 
Allocating 85 nodes.
Creating root thread attributes via pthread_attr_init.
Creating root thread via pthread_create.
thread 0 creating kids, cdepth=1
thread 1 started
Aborted
hershey% ../test_str01 
Allocating 85 nodes.
Creating root thread attributes via pthread_attr_init.
Creating root thread via pthread_create.
thread 0 creating kids, cdepth=1
thread 1 started
Aborted
hershey% uname -r
2.4.19
hershey% ulimit -a
core file size        (blocks, -c) 200000
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 256
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 7168
virtual memory        (kbytes, -v) unlimited
hershey% ls
hershey% 



On Mon, 16 Dec 2002, Howell, David P wrote:

> Kip,
> See my comments mixed in below with [DPH]. I will see if we can get the
> first fix into the next release. The TCore patch hopefully will do what 
> you need done to get a multi-thread core file. The last will take a bit
> longer but are being worked.
> 
> Thanks,
> Dave Howell
> 
> -----Original Message-----
> From: Kip Macy [mailto:[email protected]] 
> Sent: Saturday, December 14, 2002 8:37 PM
> To: [email protected]
> Subject: [pthreads-devel] A couple of small problems
> 
> 1) My application defines its own recv. Due to the nature of dynamic
> symbol
> resolution pth_poll_ev's call to recv ends up calling the application's
> and
> not libc's. This can easily be fixed by change recv -> __recv.
> 
> I can fix this in my local tree, but unless the aforementioned behaviour
> is
> desirable I don't see any reason why it shouldn't be changed.
> [DPH] Seems like we should should be calling __recv for this case, I'll
> look
> 	for other instances where this might occur.
> 
> 2) abort() doesn't cause a core dump.
> I don't know why this is, but even when I stick a call to abort in one
> of the
> test applications I don't get a core dump.
> [DPH] Did you do the 'ulimit -c 20000' to enable core dumping? With Red
> Hat 
> 	7.1/7.2/7.3/8.0 the default will not produce core dumps. If so
> it's 
> 	something else, but I can get core files wit this.
> 
> 3) gdb doesn't show all threads for a core dump.
> This isn't terribly difficult to fix, but if you are already working on
> it an
> updated patch would be appreciated.
> [DPH] This issue has two sides, first the kernel side and then the
> debugger.
> 	There was a patch that was partially integrated into the 2.5
> kernel to
> 	stop all threads in a thread group and dump all thread contexts
> called 
> 	TCore; it's part of the CGL Linux extensions. 
> 
> 	Using TCore I am able to get multi-thread core files that gdb
> can
> 	examine. It's available for the 2.4.18 kernel, and in some form
> in the 	2.5 kernel. With it gdb is able to display all active clone
> processes 	(ie. 1-1 threads) in a thread group for a Linuxthreads
> application.
> 
> 	You might want to check with Mark Gross ([email protected])
> for  	more information and to get the latest TCore patch. The patch
> was 	jointly developed by Intel and IBM. The kernel mailing lists
> have 	additional information on what was integrated into the 2.5
> kernel
> 	late summer/fall, driven by Red Hat. 
> 
> 	The picture is not quite as good for NGPT at the moment. Gdb for
> NGPT
>       uses the Libthread_db runtime library to support gdb thread
> debugging,
>       and currently this only works for attached inferior processes
> (live
>       debug), not for core file (post-mortem) debug. As it needs help
> from
>       libthread_db to show the M:N active threads, including those
> waiting
>       to run, currently it's limited to those threads that were
> currently  	running on an active clone processes. This is still
> useful, but is not
>       complete until the complete thread state can be examined.
> 
>       A prototype to make libthread_db work with core files is in the
> works.
> 	The key change is to not use procfs to get at the memory space
> but use 
> 	the data from the core file.  
> 
> 
> 			-Kip
> 
> _______________________________________________
> pthreads-devel mailing list
> [email protected]
> http://www-124.ibm.com/developerworks/oss/mailman/listinfo/pthreads-deve
> l
>