help needed in debug please

[pmm]

hi all ,
I am working on a router which is Coded in ansi C ,it uses number of
semaphores,threads
I want to know that how can we know what threads are currently alive
in a program being executed ,I do not have the support of <bold> GDB on
my target board ,not even gdbserver,</bold> my way is very crude by
placing print stmts in between the line and knowing the status.
kindly suggest me a way to know what threads are alive as one of then
throwing a segfault I am not able to determine which one
thanks in advance
PMM

[Keith Thompson]

"pmm" <mu************@hotmail.com> writes:

I am working on a router which is Coded in ansi C ,it uses number of
semaphores,threads
I want to know that how can we know what threads are currently alive
in a program being executed ,I do not have the support of <bold> GDB on
my target board ,not even gdbserver,</bold> my way is very crude by
placing print stmts in between the line and knowing the status.
kindly suggest me a way to know what threads are alive as one of then
throwing a segfault I am not able to determine which one
thanks in advance

Standard C has no support for threads. Try a newsgroup specific to
your system, or perhaps comp.programming.threads.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

pmm wrote:

hi all ,
I am working on a router which is Coded in ansi C ,it uses number of
semaphores,threads
Then, it isn't really ANSI C, is it? (Considering that ANSI C doesn't include
semaphores or threads; those are add-ons, and outside of ANSI C's purvue)
I want to know that how can we know what threads are currently alive
in a program being executed ,I do not have the support of <bold> GDB on
my target board ,not even gdbserver,</bold> my way is very crude by
placing print stmts in between the line and knowing the status.
kindly suggest me a way to know what threads are alive as one of then
throwing a segfault I am not able to determine which one
thanks in advance

You'll have to check with the creator/supplier of the semaphore and threading
library add-on. Perhaps they can help.

FWIW, you are in a bit of a bind. Assuming that your platform doesn't support
any independant external method of checking thread status (like using process
statistics gathered by the OS, for instance), and you don't have access to any
third-party diagnostics (like gdb), then you are entirely dependant on the
tools that your vendor has provided you. You really should check with them as
to how they enable or facilitate problem diagnosis in their threading package.
Certainly, there's nothing in ANSI C that will help you, beyond those tools
that you've already found (print statements, etc.).
- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)

iD8DBQFDtiklagVFX4UWr64RAouTAJ43tEHmb1UCM+396j/pzYlULhWCqwCgq0Z5
8P+GCEgsAvaFnmZEZtN2cW4=
=4fy0
-----END PGP SIGNATURE-----

[pmm]

Hi , Thanks for the reply
Its my mistake to specify as ANSI C I am sorry for that
I am on linux Redhat 9, GCC version 3.2.2
target board is on i386-linux snapgear build for amd processor

[pmm]

Hi , Thanks for the reply
Its my mistake to specify as ANSI C I am sorry for that
I am on linux Redhat 9, GCC version 3.2.2
target board is on i386-linux snapgear build for amd processor

[Chuck F.]

pmm wrote:

Its my mistake to specify as ANSI C I am sorry for that
I am on linux Redhat 9, GCC version 3.2.2
target board is on i386-linux snapgear build for amd processor

You failed to offer the courtesy of including context and
attributions. See my sig. below for suitable means.

Whatever system you are using is immaterial. c.l.c only discusses
standard C, as specified by the appropriate ISO standards (and K&R
C). Any other flavor is off-topic, and should be taken to a
newsgroup dealing with that particular system.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

[JimS]

On 30 Dec 2005 23:23:34 -0800, "pmm" <mu************@hotmail.com>
wrote:

Hi , Thanks for the reply
Its my mistake to specify as ANSI C I am sorry for that
I am on linux Redhat 9, GCC version 3.2.2
target board is on i386-linux snapgear build for amd processor

OT

I feel your pain. I've spent my entire career debugging games
consoles and embedded systems with no debuggers. Printf is your best
friend, especially if you have an unbuffered version.
Try not starting some of the threads and see what happens.
If this is something new that's happening, go back to old working code
in your source management tool and roll versions forward until the
problem re-occurs. If it's new code, try doing a code review and
working through tough areas of code on paper. Code reviews work.
Add some exception handling to your OS. Give each thread a name at
initialisation so the exception handler can print the name of the
crashing thread.
Try building the code with maxiumum warnings and maximum standards
compliance enabled. Try building with another compiler on another
platform.

Jim

[pmm]

JimS wrote:

On 30 Dec 2005 23:23:34 -0800, "pmm" <mu************@hotmail.com>
wrote:

Hi , Thanks for the reply
Its my mistake to specify as ANSI C I am sorry for that
I am on linux Redhat 9, GCC version 3.2.2
target board is on i386-linux snapgear build for amd processor

OT

I feel your pain. I've spent my entire career debugging games
consoles and embedded systems with no debuggers. Printf is your best
friend, especially if you have an unbuffered version.
Try not starting some of the threads and see what happens.
If this is something new that's happening, go back to old working code
in your source management tool and roll versions forward until the
problem re-occurs. If it's new code, try doing a code review and
working through tough areas of code on paper. Code reviews work.
Add some exception handling to your OS. Give each thread a name at
initialisation so the exception handler can print the name of the
crashing thread.
Try building the code with maxiumum warnings and maximum standards
compliance enabled. Try building with another compiler on another
platform.

Jim

Hi,
Thanks for reply
I am working on your suggestions
thanks again
bye
PMM

[pmm]

hi ,
I am sorry Mr.Keith that wont be repeated again
thanx