Re: program gets stuck

On Fri, 27 Sep 2002, Bill Abt wrote:

>
> On 09/26/2002 at 07:39:38 PM AST, Ignacio Llamas <[email protected]>
> wrote:
> >
> >
> > Hi,
> > I've tried versions 2.0.1 and 2.0.3 of NGPT on an SMP Linux Redhat 7.3
> > system with Kernel 2.4.19 patched with the patch-futex for version 2.0.3.
> > I've followed the installation instructions, to make ngpt initialize at
> > boot time (by the way, the ngptinit file that I had tried to execute
> > //bin/ngptc, which does not exist, I modified it to be /usr/bin/ngptc.
>
> This part should've been fixed in 2.0.3.  I'll have a look to see what's
> up.
>

Not in both the 'rpm' and .src.rpm versions I got. By the way, I had to
use  the .src.rpm because the library that came in the binary rpm package
contained some undefined references to functions supposed to be in
GLIBC2.0 or 2.1 which the linker could not find (these were 4
references, I can't remember them now...)

> > So as I was saying, I decided to give a try to NGPT. So I installed it
> and
> > recompiled the application after that. But it gets stuck before the main
> > window is spawned, as if all threads were sleeping...
> > Maybe I'm doing something wrong. Or maybe our code does something that is
> > not compatible with NGPT implementation.
> >
> > I have found almost no documentation about NGPT, and nothing that I found
> > explains this.
>
> The documentation for NGPT users is the POSIX spec ;-)  We're working on a
> design spec.

 Ok, I take note. But it will be nice to see something else about the
specifics of NGPT.

>
> > I would appreciate some hint on what could be going wrong.
> > Thank you,
> >
>
> Have you setup the gdb patch as well?  If you haven't, please set it up.
> If you have, try running the program in the debugger.  After the program
> hangs, break in using gdb and using "info threads" get a stack trace of
> each of the running threads and pass it on to us.  That'll give a clue as
> to what is going on.  The info you've passed so far doesn't give us much to
> go on.  If you have any question, post back to the list and we'll try and
> help.  Thanks.

 I had not done that before. I did that today and got nowhere. I run
gdb-ngpt and then start the program. Then, after it gets stuck I press
CTRL+C to break and type 'info threads'. Nothing is printed out by gdb.
Then I tried 'info stack' or 'bt' and I get just this:

(gdb) info threads
(gdb) bt
#0  0x420e45ed in syscall () from /lib/i686/libc.so.6
(gdb)

 Then I run ps and grep for the name of the program and see that four
threads are running, two spawned by the main thread, and a fourth one
spawned by the third one. So I attach gdb to each one of them, and
printing the stack of unction calls I see the last two threads are calling
nanosleep(), that we use before calling sched_yield(); to yield cpu time
to the other threads.
I can't attach to the first thread because is the main one and it already
has a gdb attached to it. The second thread however has the following call
stack:

(gdb) bt
#0  0x420e45ed in syscall () from /lib/i686/libc.so.6
#1  0x404bab6c in __DTOR_END__ () from /usr/lib/libpthread.so.20


I must say I have programmed very little with Threads before and I'm
quite new to the  project we are working on (so I did not program all the
multithreading crossplatform wrappers used here). Windows and IRIX
multi-threading work better for us, though.

>
> BTW, the pthreads-devel list is a very active list and you may run into
> someone who's experienced the problem and dealt with it before.  Might want
> to post there as well in the meantime.

I posted this there too...

>
> Regards,
>      Bill Abt
>      Senior Software Engineer
>      Next Generation POSIX Threading for Linux
>      IBM Cambridge, MA, USA 02142
>      Ext: +(00)1 603-673-3440
>      T/L: 253-9938
>      Cell: +(00)1 617-803-7514
>      [email protected] or [email protected]
>      http://oss.software.ibm.com/developerworks/opensource/pthreads
>

Thank you for yor help.

	-- Ignacio Llamas