RE: A couple of small problems

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