How to analyze a core dump?

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

How to analyze a core dump?

Luca Olivetti-2
Hello,

I'm trying to debug a segment violation, I compiled the program with -g,
but analyzing the core dump isn't really helpful, maybe the "warning
can't read pathname for load map" is the cause? Or it's possible that
it's caused by some of the c libraries used having no debug symbols? Any
hint?
Here's my gdb session:


$ gdb ./botphone core.28682
GNU gdb 6.6-1mdv2007.1 (Mandriva Linux release 2007.1)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-mandriva-linux-gnu"...
Using host libthread_db library "/lib/i686/libthread_db.so.1".

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /usr/local/lib/liblinphone.so.1...done.
Loaded symbols for /usr/local/lib/liblinphone.so.1
Reading symbols from /lib/libusb-0.1.so.4...done.
Loaded symbols for /lib/libusb-0.1.so.4
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/i686/libpthread.so.0...done.
Loaded symbols for /lib/i686/libpthread.so.0
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /usr/local/lib/libquickstream.so.0...done.
Loaded symbols for /usr/local/lib/libquickstream.so.0
Reading symbols from /usr/lib/libosip2.so.3...done.
Loaded symbols for /usr/lib/libosip2.so.3
Reading symbols from /usr/lib/libosipparser2.so.3...done.
Loaded symbols for /usr/lib/libosipparser2.so.3
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/i686/librt.so.1...done.
Loaded symbols for /lib/i686/librt.so.1
Reading symbols from /lib/libintl.so.8...done.
Loaded symbols for /lib/libintl.so.8
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/local/lib/libmediastreamer.so.0...done.
Loaded symbols for /usr/local/lib/libmediastreamer.so.0
Reading symbols from /usr/local/lib/libortp.so.5...done.
Loaded symbols for /usr/local/lib/libortp.so.5
Reading symbols from /usr/lib/libasound.so.2...done.
Loaded symbols for /usr/lib/libasound.so.2
Reading symbols from /usr/lib/libspeex.so.1...done.
Loaded symbols for /usr/lib/libspeex.so.1
Reading symbols from /lib/i686/libm.so.6...done.
Loaded symbols for /lib/i686/libm.so.6
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_nis.so.2...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnss_dns.so.2...done.
Loaded symbols for /lib/libnss_dns.so.2
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Core was generated by `./botphone -v -v -v -c /home/luca/.linphonerc -C
/home/luca/agenda'.
Program terminated with signal 11, Segmentation fault.
#0  0x080593ea in SYSTEM_GETERRNO$$LONGINT ()
(gdb) bt f
#0  0x080593ea in SYSTEM_GETERRNO$$LONGINT ()
No symbol table info available.
#1  0x08060442 in SYSTEM_REENABLE_SIGNAL$LONGINT$$BOOLEAN ()
No symbol table info available.
#2  0x08060580 in SYSTEM_SIGNALTORUNERROR$LONGINT$PSIGINFO$PUCONTEXT ()
No symbol table info available.
#3  0x08059bec in ?? ()
No symbol table info available.
#4  0x0000000b in ?? ()
No symbol table info available.
#5  0xb6b5412c in ?? ()
No symbol table info available.
#6  0xb6b541ac in ?? ()
No symbol table info available.
#7  0x0000000b in ?? ()
No symbol table info available.
#8  0x00000000 in ?? ()
No symbol table info available.
(gdb)


Bye
--
Luca
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

John Coppens
On Sun, 10 Jun 2007 21:30:09 +0200
Luca Olivetti <[hidden email]> wrote:

> I'm trying to debug a segment violation, I compiled the program with
> -g, but analyzing the core dump isn't really helpful, maybe the
> "warning can't read pathname for load map" is the cause? Or it's
> possible that it's caused by some of the c libraries used having no
> debug symbols? Any hint?

I'm not too experienced in this, but I suspect a good first step would be
to ask for a backtrace (bt) in gdb, after the segfault occured. You'll
see the steps that led to the actual segfault, starting from the main
program till the library function that failed. Don't immediately suspect
the library - go back to the last line of your program and check if all
things are normal at _that_ point.

AFAIK, core dumps are not really related with gdb, but are generated by
the kernel, and should be the last step to fall back on. A backtrace in
gdb is generally more helpful.

John
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

Luca Olivetti-2
En/na John Coppens ha escrit:

> On Sun, 10 Jun 2007 21:30:09 +0200
> Luca Olivetti <[hidden email]> wrote:
>
>> I'm trying to debug a segment violation, I compiled the program with
>> -g, but analyzing the core dump isn't really helpful, maybe the
>> "warning can't read pathname for load map" is the cause? Or it's
>> possible that it's caused by some of the c libraries used having no
>> debug symbols? Any hint?
>
> I'm not too experienced in this, but I suspect a good first step would be
> to ask for a backtrace (bt) in gdb, after the segfault occured. You'll
> see the steps that led to the actual segfault, starting from the main
> program till the library function that failed. Don't immediately suspect
> the library - go back to the last line of your program and check if all
> things are normal at _that_ point.
>
> AFAIK, core dumps are not really related with gdb, but are generated by
> the kernel, and should be the last step to fall back on. A backtrace in
> gdb is generally more helpful.

I don't know gdb well, but it should be capable to show a backtrace
using a core file (that's what I was trying to do). The program doesn't
work if I run it under gdb (I don't know why, but I think it has
problems with thread), that's why I was trying to use a core. Also it's
impossible to debug the program using Lazarus (again, I think, due to
threads, and, yes, I tried a separate X server as per the instructions
in the wiki)

Bye
--
Luca
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

ik-6
In reply to this post by Luca Olivetti-2
Hi,

On 6/10/07, Luca Olivetti <[hidden email]> wrote:

> Hello,
>
> I'm trying to debug a segment violation, I compiled the program with -g,
> but analyzing the core dump isn't really helpful, maybe the "warning
> can't read pathname for load map" is the cause? Or it's possible that
> it's caused by some of the c libraries used having no debug symbols? Any
> hint?
> Here's my gdb session:
>
>
> $ gdb ./botphone core.28682

Try the following:

gdb -c botphone core.28682

inside gdb you can do things such as back-trace.

> GNU gdb 6.6-1mdv2007.1 (Mandriva Linux release 2007.1)
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i586-mandriva-linux-gnu"...
> Using host libthread_db library "/lib/i686/libthread_db.so.1".
>
> warning: Can't read pathname for load map: Input/output error.
> Reading symbols from /usr/local/lib/liblinphone.so.1...done.
> Loaded symbols for /usr/local/lib/liblinphone.so.1
> Reading symbols from /lib/libusb-0.1.so.4...done.
> Loaded symbols for /lib/libusb-0.1.so.4
> Reading symbols from /lib/libdl.so.2...done.
> Loaded symbols for /lib/libdl.so.2
> Reading symbols from /lib/i686/libpthread.so.0...done.
> Loaded symbols for /lib/i686/libpthread.so.0
> Reading symbols from /lib/i686/libc.so.6...done.
> Loaded symbols for /lib/i686/libc.so.6
> Reading symbols from /usr/local/lib/libquickstream.so.0...done.
> Loaded symbols for /usr/local/lib/libquickstream.so.0
> Reading symbols from /usr/lib/libosip2.so.3...done.
> Loaded symbols for /usr/lib/libosip2.so.3
> Reading symbols from /usr/lib/libosipparser2.so.3...done.
> Loaded symbols for /usr/lib/libosipparser2.so.3
> Reading symbols from /lib/libnsl.so.1...done.
> Loaded symbols for /lib/libnsl.so.1
> Reading symbols from /lib/i686/librt.so.1...done.
> Loaded symbols for /lib/i686/librt.so.1
> Reading symbols from /lib/libintl.so.8...done.
> Loaded symbols for /lib/libintl.so.8
> Reading symbols from /lib/ld-linux.so.2...done.
> Loaded symbols for /lib/ld-linux.so.2
> Reading symbols from /usr/local/lib/libmediastreamer.so.0...done.
> Loaded symbols for /usr/local/lib/libmediastreamer.so.0
> Reading symbols from /usr/local/lib/libortp.so.5...done.
> Loaded symbols for /usr/local/lib/libortp.so.5
> Reading symbols from /usr/lib/libasound.so.2...done.
> Loaded symbols for /usr/lib/libasound.so.2
> Reading symbols from /usr/lib/libspeex.so.1...done.
> Loaded symbols for /usr/lib/libspeex.so.1
> Reading symbols from /lib/i686/libm.so.6...done.
> Loaded symbols for /lib/i686/libm.so.6
> Reading symbols from /lib/libnss_files.so.2...done.
> Loaded symbols for /lib/libnss_files.so.2
> Reading symbols from /lib/libnss_nis.so.2...done.
> Loaded symbols for /lib/libnss_nis.so.2
> Reading symbols from /lib/libnss_dns.so.2...done.
> Loaded symbols for /lib/libnss_dns.so.2
> Reading symbols from /lib/libresolv.so.2...done.
> Loaded symbols for /lib/libresolv.so.2
> Reading symbols from /lib/libgcc_s.so.1...done.
> Loaded symbols for /lib/libgcc_s.so.1
> Core was generated by `./botphone -v -v -v -c /home/luca/.linphonerc -C
> /home/luca/agenda'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x080593ea in SYSTEM_GETERRNO$$LONGINT ()
> (gdb) bt f
> #0  0x080593ea in SYSTEM_GETERRNO$$LONGINT ()
> No symbol table info available.
> #1  0x08060442 in SYSTEM_REENABLE_SIGNAL$LONGINT$$BOOLEAN ()
> No symbol table info available.
> #2  0x08060580 in SYSTEM_SIGNALTORUNERROR$LONGINT$PSIGINFO$PUCONTEXT ()
> No symbol table info available.
> #3  0x08059bec in ?? ()
> No symbol table info available.
> #4  0x0000000b in ?? ()
> No symbol table info available.
> #5  0xb6b5412c in ?? ()
> No symbol table info available.
> #6  0xb6b541ac in ?? ()
> No symbol table info available.
> #7  0x0000000b in ?? ()
> No symbol table info available.
> #8  0x00000000 in ?? ()
> No symbol table info available.
> (gdb)
>
>
> Bye
> --
> Luca


Ido
--
http://ik.homelinux.org/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

Luca Olivetti-2
En/na ik ha escrit:

> Hi,
>
> On 6/10/07, Luca Olivetti <[hidden email]> wrote:
>> Hello,
>>
>> I'm trying to debug a segment violation, I compiled the program with -g,
>> but analyzing the core dump isn't really helpful, maybe the "warning
>> can't read pathname for load map" is the cause? Or it's possible that
>> it's caused by some of the c libraries used having no debug symbols? Any
>> hint?
>> Here's my gdb session:
>>
>>
>> $ gdb ./botphone core.28682
>
> Try the following:
>
> gdb -c botphone core.28682

Yes, that was the first incantation I tried, but it couldn't even
resolve the name of the function where the sigsev happened
(SYSTEM_GETERRNO$$LONGINT)

Bye

--
Luca

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

Luca Olivetti-2
In reply to this post by Luca Olivetti-2
En/na Luca Olivetti ha escrit:

> Hello,
>
> I'm trying to debug a segment violation, I compiled the program with -g,
> but analyzing the core dump isn't really helpful, maybe the "warning
> can't read pathname for load map" is the cause? Or it's possible that
> it's caused by some of the c libraries used having no debug symbols? Any
> hint?
> Here's my gdb session:
>
>
> $ gdb ./botphone core.28682
[...]

> Core was generated by `./botphone -v -v -v -c /home/luca/.linphonerc -C
> /home/luca/agenda'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x080593ea in SYSTEM_GETERRNO$$LONGINT ()
> (gdb) bt f
> #0  0x080593ea in SYSTEM_GETERRNO$$LONGINT ()
> No symbol table info available.
> #1  0x08060442 in SYSTEM_REENABLE_SIGNAL$LONGINT$$BOOLEAN ()
> No symbol table info available.
> #2  0x08060580 in SYSTEM_SIGNALTORUNERROR$LONGINT$PSIGINFO$PUCONTEXT ()
> No symbol table info available.
> #3  0x08059bec in ?? ()
> No symbol table info available.
> #4  0x0000000b in ?? ()
> No symbol table info available.
> #5  0xb6b5412c in ?? ()
> No symbol table info available.
> #6  0xb6b541ac in ?? ()
> No symbol table info available.
> #7  0x0000000b in ?? ()
> No symbol table info available.
> #8  0x00000000 in ?? ()
> No symbol table info available.
> (gdb)

No suggestions? Is there some special option (apart from -g) that I
should specify to compile/link my program?

Bye
--
Luca
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

Jonas Maebe-2

On 14 jun 2007, at 19:04, Luca Olivetti wrote:

> No suggestions? Is there some special option (apart from -g) that I  
> should specify to compile/link my program?

No. But the garbage backtrace means that either your gdb cannot parse  
the signal handler frame, or that your program corrupted the call stack.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

Luca Olivetti-2
En/na Jonas Maebe ha escrit:
>
> On 14 jun 2007, at 19:04, Luca Olivetti wrote:
>
>> No suggestions? Is there some special option (apart from -g) that I
>> should specify to compile/link my program?
>
> No. But the garbage backtrace means that either your gdb cannot parse
> the signal handler frame, or that your program corrupted the call stack.

Well, I'm starting to get desperate, I cannot debug where the sigsev
occurs, I put a bazillion writeln and still I cannot see where the
problem is. I can reproduce the sigsev at will, only I cannot see where
it happens. I suspect it's one of the threads in the c library
(linphonecore, http://www.linphone.org) I'm using (since in all of my
threads I put writeln in the critical places, as well as in all the
callbacks from said library), alas there's no sigsev when the same
library is driven by the c console program that comes with it (linphonec).
At one point I though the problem was in CheckSynchronize (since the
last writeln before the sigsev was right before calling it), but it was
just a timing coincidence (I was calling it with 1000, then when I tried
  with 0 I saw the sigsev right in the middle of a debugging printf in
the library).
Maybe it's not a good idea to mix c multithreaded libraries and pascal
code? Any special unit I should use? (I already tried cmem and it made
no difference).
If I cannot solve it I think I'll have to write a small backend program
in c that communicates with pascal either through stdin/stdout
redirection or with a socket.

Bye
--
Luca

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

Tom Walsh-2
Luca Olivetti wrote:

> En/na Jonas Maebe ha escrit:
>>
>> On 14 jun 2007, at 19:04, Luca Olivetti wrote:
>>
>>> No suggestions? Is there some special option (apart from -g) that I
>>> should specify to compile/link my program?
>>
>> No. But the garbage backtrace means that either your gdb cannot parse
>> the signal handler frame, or that your program corrupted the call stack.
>
> Well, I'm starting to get desperate, I cannot debug where the sigsev
> occurs, I put a bazillion writeln and still I cannot see where the
> problem is. I can reproduce the sigsev at will, only I cannot see
> where it happens. I suspect it's one of the threads in the c library
> (linphonecore, http://www.linphone.org) I'm using (since in all of my
> threads I put writeln in the critical places, as well as in all the
> callbacks from said library), alas there's no sigsev when the same
> library is driven by the c console program that comes with it
> (linphonec).
> At one point I though the problem was in CheckSynchronize (since the
> last writeln before the sigsev was right before calling it), but it
> was just a timing coincidence (I was calling it with 1000, then when I
> tried  with 0 I saw the sigsev right in the middle of a debugging
> printf in the library).
> Maybe it's not a good idea to mix c multithreaded libraries and pascal
> code? Any special unit I should use? (I already tried cmem and it made
> no difference).
> If I cannot solve it I think I'll have to write a small backend
> program in c that communicates with pascal either through stdin/stdout
> redirection or with a socket.
>
> Bye
IIRC, it is 'gcc -c <corefilename>'

TomW


--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------------------------------------------


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

Tom Walsh-2
In reply to this post by Luca Olivetti-2
Luca Olivetti wrote:

> En/na Jonas Maebe ha escrit:
>>
>> On 14 jun 2007, at 19:04, Luca Olivetti wrote:
>>
>>> No suggestions? Is there some special option (apart from -g) that I
>>> should specify to compile/link my program?
>>
>> No. But the garbage backtrace means that either your gdb cannot parse
>> the signal handler frame, or that your program corrupted the call stack.
>
> Well, I'm starting to get desperate, I cannot debug where the sigsev
> occurs, I put a bazillion writeln and still I cannot see where the
> problem is. I can reproduce the sigsev at will, only I cannot see
> where it happens. I suspect it's one of the threads in the c library
> (linphonecore, http://www.linphone.org) I'm using (since in all of my
> threads I put writeln in the critical places, as well as in all the
> callbacks from said library), alas there's no sigsev when the same
> library is driven by the c console program that comes with it
> (linphonec).
> At one point I though the problem was in CheckSynchronize (since the
> last writeln before the sigsev was right before calling it), but it
> was just a timing coincidence (I was calling it with 1000, then when I
> tried  with 0 I saw the sigsev right in the middle of a debugging
> printf in the library).
> Maybe it's not a good idea to mix c multithreaded libraries and pascal
> code? Any special unit I should use? (I already tried cmem and it made
> no difference).
> If I cannot solve it I think I'll have to write a small backend
> program in c that communicates with pascal either through stdin/stdout
> redirection or with a socket.
>
> Bye
Nope, it is 'gdb -c <corefilename>'.  Sorry :-(

TomW


--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net http://cyberiansoftware.com http://openzipit.org
"Windows? No thanks, I have work to do..."
----------------------------------------------------


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

Luca Olivetti-2
En/na Tom Walsh ha escrit:

> Nope, it is 'gdb -c <corefilename>'.  Sorry :-(

Been there, done that, got the t-shirt.
http://article.gmane.org/gmane.comp.compilers.free-pascal.general/8211

thanks for trying.

--
Luca

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

Jonas Maebe-2
In reply to this post by Luca Olivetti-2

On 25 jun 2007, at 22:44, Luca Olivetti wrote:

> En/na Jonas Maebe ha escrit:
>> On 14 jun 2007, at 19:04, Luca Olivetti wrote:
>>> No suggestions? Is there some special option (apart from -g) that  
>>> I should specify to compile/link my program?
>> No. But the garbage backtrace means that either your gdb cannot  
>> parse the signal handler frame, or that your program corrupted the  
>> call stack.
>
> Well, I'm starting to get desperate

Try compiling everything with -gv and using valgrind


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

Luca Olivetti-2
En/na Jonas Maebe ha escrit:

>
> On 25 jun 2007, at 22:44, Luca Olivetti wrote:
>
>> En/na Jonas Maebe ha escrit:
>>> On 14 jun 2007, at 19:04, Luca Olivetti wrote:
>>>> No suggestions? Is there some special option (apart from -g) that I
>>>> should specify to compile/link my program?
>>> No. But the garbage backtrace means that either your gdb cannot parse
>>> the signal handler frame, or that your program corrupted the call stack.
>>
>> Well, I'm starting to get desperate
>
> Try compiling everything with -gv and using valgrind

running under valgrind I cannot reproduce the segment violation :-(
I should read valgrind documentation to interpret the data it prints
out, however there's something that strikes me:

==5051== Thread 1:
==5051== Conditional jump or move depends on uninitialised value(s)
==5051==    at 0x808DB59: BUTLER_TBUTLERPHONE_$__RECEIVE$ANSISTRING
(butler.pas:444)
==5051==    by 0x808F7B4: BUTLER_TSTATUSTHREAD_$__RECEIVE (butler.pas:697)
==5051==    by 0x806BAA0: CLASSES_CHECKSYNCHRONIZE$LONGINT (in
/home/luca/botphone/botphone)
==5051==    by 0x804A96B: main (botphone.lpr:568)

where line 444 is:

442:  L:=length(s);
443:  if L<1 then exit;
444:  case s[1] of

so I can't see how it could possibly be uninitialized.

Bye
--
Luca
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

Cesar Romero-2
Where S is initialized?
I only see L initialized.

[]s


Cesar Romero
>
> 442:  L:=length(s);
> 443:  if L<1 then exit;
> 444:  case s[1] of
>
> so I can't see how it could possibly be uninitialized.
>
> Bye

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

Luca Olivetti-2
En/na Cesar Romero ha escrit:

> Where S is initialized?
> I only see L initialized.
>
> []s
>
>
> Cesar Romero
>>
>> 442:  L:=length(s);
>> 443:  if L<1 then exit;
>> 444:  case s[1] of
>>
>> so I can't see how it could possibly be uninitialized.

nothwithstanding the fact that if length(s)<1 line 444 won't be
executed, so the "uninitialized" should be flagged in line 442, I know
that this chunk is inside

procedure TButlerPhone.Receive(s: string);

so s is a parameter.
This procedure is called exclusively from

procedure TStatusThread.Receive;
begin
   FOwner.Receive(FData)
end;

(FOwner is a TButlerPhone)

which in turn is called only here:

           FData:=copy(buffer,i+2,L-1);
           if buffer[i+L+1]=checksum(FData) then
           begin
            if not terminated then synchronize(@Receive);
           end else


Bye
--
Luca

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

Vinzent Höfler
On Tuesday 26 June 2007 17:26, Luca Olivetti wrote:

> procedure TButlerPhone.Receive(s: string);
>
> so s is a parameter.
> This procedure is called exclusively from
>
> procedure TStatusThread.Receive;
> begin
>    FOwner.Receive(FData)
> end;
>
> (FOwner is a TButlerPhone)
>
> which in turn is called only here:
>
>            FData:=copy(buffer,i+2,L-1);
>            if buffer[i+L+1]=checksum(FData) then
>            begin
>             if not terminated then synchronize(@Receive);
>            end else

Are you passing AnsiString types between threads? If that's the case try
using shortstrings or make a local copy of the parameter. And *DO NOT*
pass them to a C-library in any way!

I had several problems doing that too (and I don't mean the obvious case
if the string is changed in one thread while it's still accessed in the
other). There also seemed to be some issues with the reference
counting: if I passed a local AnsiString to a thread constructor as
argument and left the routine then, this seemed to confuse the thread
throwing SIGSEGVs occasionally. Making a copy of the string (means:
assigning it to a field in the thread instance before and using this
field from now on) inside the constructor solved this problem.

BTW, using the "disassemble" function of gdb sometimes reveals where the
unnamed routine really is, so for the

> #3  0x08059bec in ?? ()
> No symbol table info available.

"disassemble 0x8059bec" *might* help you invastigating the source of the
problem further.


HTH,

Vinzent.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

Jonas Maebe-2

On 27 jun 2007, at 08:13, Vinzent Hoefler wrote:

> There also seemed to be some issues with the reference
> counting: if I passed a local AnsiString to a thread constructor as
> argument and left the routine then, this seemed to confuse the thread
> throwing SIGSEGVs occasionally.

Maybe the parameter was declared as const? In that case, the refcount  
of the ansistring you pass isn't increased, because the compiler  
interprets the const as "the ansistring will not be changed in any  
way as long as that constructor is running". If it's a value  
parameter, it should work fine (a var parameter obviously wouldn't  
work either).


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

Vinzent Höfler
On Wednesday 27 June 2007 07:55, Jonas Maebe wrote:
> On 27 jun 2007, at 08:13, Vinzent Hoefler wrote:
> > There also seemed to be some issues with the reference
> > counting: if I passed a local AnsiString to a thread constructor as
> > argument and left the routine then, this seemed to confuse the
> > thread throwing SIGSEGVs occasionally.
>
> Maybe the parameter was declared as const?

I think so. I always do that. ;)

> In that case, the refcount of the ansistring you pass isn't increased,

Meaning that the string will be freed once I leave the routine that
called the constructor? That would explain it for sure.


Regards,

Vinzent.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

Jonas Maebe-2

On 27 jun 2007, at 08:47, Vinzent Hoefler wrote:

>> In that case, the refcount of the ansistring you pass isn't  
>> increased,
>
> Meaning that the string will be freed once I leave the routine that
> called the constructor?

Yes.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: How to analyze a core dump?

Luca Olivetti-2
In reply to this post by Vinzent Höfler
En/na Vinzent Hoefler ha escrit:

> On Tuesday 26 June 2007 17:26, Luca Olivetti wrote:
>
>> procedure TButlerPhone.Receive(s: string);
>>
>> so s is a parameter.
>> This procedure is called exclusively from
>>
>> procedure TStatusThread.Receive;
>> begin
>>    FOwner.Receive(FData)
>> end;
>>
>> (FOwner is a TButlerPhone)
>>
>> which in turn is called only here:
>>
>>            FData:=copy(buffer,i+2,L-1);
>>            if buffer[i+L+1]=checksum(FData) then
>>            begin
>>             if not terminated then synchronize(@Receive);
>>            end else
>
> Are you passing AnsiString types between threads?

yes and no: the synchronize should assure that TButlerPhone.Receive is
called from the main thread, and TStatusThread will wait until
completion of the call.

> If that's the case try
> using shortstrings or make a local copy of the parameter

I'll try that (though I think it shouldn't be necessary)

>. And *DO NOT*
> pass them to a C-library in any way!

Not even surrounded by PChar()?
(now that I think of it, it could well be that the library is storing
the pointer and using it later when it is no longer valid, let me
check....no, it doesn't).

> I had several problems doing that too (and I don't mean the obvious case
> if the string is changed in one thread while it's still accessed in the
> other). There also seemed to be some issues with the reference
> counting: if I passed a local AnsiString to a thread constructor as
> argument and left the routine then, this seemed to confuse the thread
> throwing SIGSEGVs occasionally. Making a copy of the string (means:
> assigning it to a field in the thread instance before and using this
> field from now on) inside the constructor solved this problem.

Do you mean like (absurd example, I know)

TMyThread.Constructor(astring:string);
begin
   FString:=astring;
   FNum:=StrToInt(FString);
   inherited create(false);
end;


instead of

TMyThread.Constructor(astring:string);
begin
   FNum:=StrToInt(astring);
   inherited create(false);
end;


again, I don't think it should be necessary if you're only going to use
astring in the constructor.

>
> BTW, using the "disassemble" function of gdb sometimes reveals where the
> unnamed routine really is, so for the
>
>> #3  0x08059bec in ?? ()
>> No symbol table info available.
>
> "disassemble 0x8059bec" *might* help you invastigating the source of the
> problem further.

thanks, I'll give it a try, though the last time I used assembly
language was with a Z80 when it was new ;-)

Bye
--
Luca
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
12