Re: Multithreaded Apps on Linux

Re: Multithreaded Apps on Linux

[Davy Durham]

Oh yeah... it works fine when I run it....  (yeah you ask: "Then why is he
debugging it"...   I wanna see something ;)  )



Davy Durham wrote:

> I've tried gdb 5.0 and have now downgraded to 4.18
>
> When I debug my multithreaded app which run on linux, it keeps stopping
> (with no message) and I have to "cont" to get it to continue...  Then it
> eventually give a message:
>
>     Program received signal SIG32, Real-time event 32.
>     0x4013017e in sigsuspend () from /lib/libc.so.6
>
> And then I cannot continue at all....
>
> What's going on here...   5.0 gives the same results.....
>
> Any Info, Thanks,
>     Davy

Re: Multithreaded Apps on Linux

[Frank Ch. Eigler]

Davy Durham <david.durham@wcom.com> writes:

: [...]
: When I debug my multithreaded app which run on linux, it keeps stopping
: (with no message) and I have to "cont" to get it to continue...  Then it
: eventually give a message:
:     Program received signal SIG32, Real-time event 32.
:     0x4013017e in sigsuspend () from /lib/libc.so.6
: [...]

When debugging this program, onsider asking gdb to 
        handle SIG32 pass nostop
either in your .gdbinit or on the (gdb) command line.

- FChE
From jimb@zwingli.cygnus.com Wed Nov 29 16:34:00 2000
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: Davy Durham <david.durham@wcom.com>
Cc: gdb@sources.redhat.com
Subject: Re: Multithreaded Apps on Linux
Date: Wed, 29 Nov 2000 16:34:00 -0000
Message-id: <npn1eis3ft.fsf@zwingli.cygnus.com>
References: <3A252F35.63A6F2A8@wcom.com>
X-SW-Source: 2000-11/msg00275.html
Content-length: 689

I don't remember about 5.0, but I know that current versions of GDB
handle this correctly, if your copy of glibc and LinuxThreads is new
enough.


Davy Durham <david.durham@wcom.com> writes:

> 
> I've tried gdb 5.0 and have now downgraded to 4.18
> 
> When I debug my multithreaded app which run on linux, it keeps stopping
> (with no message) and I have to "cont" to get it to continue...  Then it
> eventually give a message:
> 
>     Program received signal SIG32, Real-time event 32.
>     0x4013017e in sigsuspend () from /lib/libc.so.6
> 
> And then I cannot continue at all....
> 
> What's going on here...   5.0 gives the same results.....
> 
> Any Info, Thanks,
>     Davy
> 
> 
From ac131313@cygnus.com Wed Nov 29 17:43:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: GDB Discussion <gdb@sourceware.cygnus.com>
Subject: free() vs xfree() vs FREEIF() vs ISO-C
Date: Wed, 29 Nov 2000 17:43:00 -0000
Message-id: <3A25AEDA.5A57A0F2@cygnus.com>
X-SW-Source: 2000-11/msg00276.html
Content-length: 698

Hello,

One of the issues that fell out of the alloca() discussion was the
portability of free().  While ISO-C guarentees that free(NULL) doesn't
dump core, many pre-ISO-C libc's don't offer that guarentee.

I can think of several ways of refining the coding standard to avoid
this:

	o	Add/use xfree() which
		would guard against NULL.

	o	adopt FREEIF() for for
		the same reason

	o	leave things as is
		and assume people will
		remember to check the
		arg before calling xfree().

Does anyone have any thoughts?  I tend towards the first one as that is
fairly easy to implement.  If adopted, I'd beg/borrow/con someone into
converting all free() and free((PTR)) calls into xfree() :-)

	Andrew
From ac131313@cygnus.com Wed Nov 29 17:52:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Duffek <nsd@cygnus.com>, GDB Discussion <gdb@sourceware.cygnus.com>
Subject: alloca() in gdbint.texi
Date: Wed, 29 Nov 2000 17:52:00 -0000
Message-id: <3A25B0FC.33AF81D6@cygnus.com>
X-SW-Source: 2000-11/msg00277.html
Content-length: 544

Nick,

Looks like the alloca() discussion has died down.  If you're still
motivated then now is probably the time to go back through and come up
with a section explaining alloca() and its limitations.

My only thought is to make it part of a larger memory management section
vis:

	Memmory Management

		Malloc()

		GDB uses xmalloc() and friends.  Do not call malloc(), realloc(),
asprintf(), etc directly.

		You can assume that xrealloc(NULL, size) is well behaved.

		See also cleanups.


		Alloca()

		something goes here.

enjoy,
	Andrew
From chastain@cygnus.com Wed Nov 29 18:27:00 2000
From: Michael Elizabeth Chastain <chastain@cygnus.com>
To: ac131313@cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: free() vs xfree() vs FREEIF() vs ISO-C
Date: Wed, 29 Nov 2000 18:27:00 -0000
Message-id: <200011300230.SAA11063@train2.cygnus.com>
X-SW-Source: 2000-11/msg00278.html
Content-length: 179

Andrew suggests ...

	o	Add/use xfree() which
		would guard against NULL.

... <aol> I like this one too </aol>.  It's pretty natural that xmalloc
and xfree go together.

Michael
From yxw@chinacluster.com Wed Nov 29 19:52:00 2000
From: Yu Xuanwei <yxw@chinacluster.com>
To: gdb@sources.redhat.com
Subject: Remote Debugging
Date: Wed, 29 Nov 2000 19:52:00 -0000
Message-id: <3A263F26.7A6D83D7@chinacluster.com>
X-SW-Source: 2000-11/msg00279.html
Content-length: 851

Hi, buddies:

I've scanned all gdb mailist archives and gdb manual. I'm still
confused.
What I 've done:
1. cross-compile gdbserver by m68k-pic-coff compiler.
2. Download gdbserver into M68EZ328 ADS board.
3. Run it as: EZ328> gdbserver MyHost:port test, (test is stripped).

4. Native compile(Intel) in host: gcc -g test.c -o htest, (test.c is
just a HelloWorld)
5. Run gdb in Intel host: MyHost> gdb
gdb> target remote EZ328:port
gdb> symbol-file htest
gdb> b main
gdb> c
gdb> n
.
.
.
gdb> Program exit normally

6. See 'Hello World!' in target screen, and the gdbserver end when the
gdb session is over.

Idoubt whether I was right. I don't know how to 'load'. I don't know how

to prevent gdbserver exiting after one gdb session. I don't understand
whether I got the exact case in target via TCP. I feel unconfident.

Thanks a lot,

Yu Xuanwei