In article , Serge Wenger wrote:
> Hello,
>
> I run on Linux.I have a big multithread application with many dynamic
> library. Sometimes I receive a SIGSEGV.
>
> How is it possible to obtain more informations, call stack or
> something else to help me to find my bug(s)?

man gdb

Good luck,
Apostolos

--
Replace earth.space with gmail.com for a valid e-mail

Thank for the suggestion.

It was not what I hope. I search for a method to give the call stack when an
error occurs on a customer machine, not only on development machine.

Thanks

Serge

"tosoAplos" a écrit dans le message de news:
ddi0am$2283$1@ulysses.noc.ntua.gr...
> In article , Serge Wenger wrote:
>> Hello,
>>
>> I run on Linux.I have a big multithread application with many dynamic
>> library. Sometimes I receive a SIGSEGV.
>>
>> How is it possible to obtain more informations, call stack or
>> something else to help me to find my bug(s)?
>
> man gdb
>
> Good luck,
> Apostolos
>
> --
> Replace earth.space with gmail.com for a valid e-mail

Please don't top-post. You can use OE-QuoteFix for a proper arrangement
of quotes ( http://home.in.tum.de/~jain/software/oe-quotefix/ )

On Ôåô, 17 Áýã 2005 at 09:06 GMT, Serge Wenger wrote:
> "tosoAplos" a écrit dans le message de news:
> ddi0am$2283$1@ulysses.noc.ntua.gr...
>> In article , Serge Wenger wrote:
>>>
>>> I run on Linux.I have a big multithread application with many dynamic
>>> library. Sometimes I receive a SIGSEGV.
>>>
>>> How is it possible to obtain more informations, call stack or
>>> something else to help me to find my bug(s)?
>>
>> man gdb
>>
>> Apostolos
>
> Thank for the suggestion.
>
> It was not what I hope. I search for a method to give the call stack when an
> error occurs on a customer machine, not only on development machine.
>
> Serge

If you have the source, you can use assert(), or other debugging
techniques, in certain places of your code to find out what's wrong.

If you don't have the source code, I know gdb can do remote debugging
but I've never used it remotely.

Apostolos

--
Replace earth.space with gmail.com for a valid e-mail

"Serge Wenger" writes:

> Thank for the suggestion.

Please do not top-post:
http://catb.org/~esr/jargon/html/T/top-post.html

> It was not what I hope. I search for a method to give the call stack when an
> error occurs on a customer machine, not only on development machine.

The exact same method works on the customer machine.
Just ask customer to run your program under gdb.

There are also routines in glibc, which allow you to print crash
stack trace: backtrace() and backtrace_symbols() [do "info libc"
-> Backtraces].

You'll have to install a SIGSEGV handler, print the stack trace
and abort(). Further details here:
http://groups.google.com/group/comp....4ff8fb2959797a

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

"Serge Wenger" writes:

>>> How is it possible to obtain more informations, call stack or
>>> something else to help me to find my bug(s)?

Oh, and one more thing: run your app ander valgrind, and be sure
to fix all bugs it finds.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

> "Serge Wenger" writes:
>
>>>> How is it possible to obtain more informations, call stack or
>>>> something else to help me to find my bug(s)?
>
> Oh, and one more thing: run your app ander valgrind, and be sure
> to fix all bugs it finds.
>
> Cheers,
> --
> In order to understand recursion you must first understand recursion.
> Remove /-nsp/ for email.

Thanks for your help

Serge

PS: Sorry for the top-post

>>>Hello,
>>>
>>>I run on Linux.I have a big multithread application with many dynamic
>>>library. Sometimes I receive a SIGSEGV.
>>>
>>>How is it possible to obtain more informations, call stack or
>>>something else to help me to find my bug(s)?
>>
>>man gdb
>>
>>Good luck,
>>Apostolos
>>
>>--
>>Replace earth.space with gmail.com for a valid e-mail
>
>
>
The idea would be to get a core dumped on your client. Then you can
fetch it back to your developpment platform and analyse it with gdb as
Apostolos suggested.

Of course to get a "juicy" core it would be better you have the source
that you can compile on debug mode. Also check ulimit is set correctly
on your client side.