* [Buildroot] core file
[not found] <DC8F7388218A402C9FEADA4D9CC577B3@JohanW7>
@ 2012-03-15 7:00 ` Thomas Petazzoni
2012-03-15 12:17 ` Sagaert Johan
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2012-03-15 7:00 UTC (permalink / raw)
To: buildroot
Hello,
Please keep the Buildroot list in the loop.
Le Thu, 15 Mar 2012 03:02:29 +0100,
"Sagaert Johan" <sagaert.johan@skynet.be> a ?crit :
> I have the core file and gdb on the target.
>
> What should i do with it, i never used gdb on the command line so far.
If you have gdb on the target, then:
gdb /usr/bin/curl -c /path/to/the/core/file
By the way, if you are using BR2_CCACHE, then please disable it and do
a complete rebuild to see if it works better.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] core file
2012-03-15 7:00 ` [Buildroot] core file Thomas Petazzoni
@ 2012-03-15 12:17 ` Sagaert Johan
2012-03-15 13:19 ` Thomas Petazzoni
0 siblings, 1 reply; 6+ messages in thread
From: Sagaert Johan @ 2012-03-15 12:17 UTC (permalink / raw)
To: buildroot
Hi
This is the result of gdb /usr/bin/curl -c /root/core
The virtual memory error is strange since my board only has 64MB
# ulimit -c unlimited
# curl
ELF header=0x40074000
First Dynamic section entry=0x40083ef0
Scanning DYNAMIC section
Done scanning DYNAMIC section
About to do library loader relocations
Done relocating ldso; we can now use globals and make function calls!
_dl_get_ready_to_run:454: Cool, ldso survived making function calls
_dl_malloc:246: mmapping more memory
_dl_ldsopath_init:162: Lib Loader: (0x40074000) /lib/ld-uClibc.so.0: using path: /lib
_dl_get_ready_to_run:1042: Loading: (0x4009e000) /usr/lib/libcurl.so.4
_dl_get_ready_to_run:1042: Loading: (0x40110000) /usr/lib/libz.so.1
_dl_get_ready_to_run:1042: Loading: (0x40208000) /lib/libc.so.0
_dl_get_ready_to_run:1042: Loading: (0x402a3000) /usr/lib/libssl.so.1.0.0
_dl_get_ready_to_run:1042: Loading: (0x4030e000) /usr/lib/libcrypto.so.1.0.0
_dl_get_ready_to_run:1042: Loading: (0x40110000) /usr/lib/libz.so.1
_dl_get_ready_to_run:1042: Loading: (0x4019b000) /lib/libgcc_s.so.1
_dl_get_ready_to_run:1042: Loading: (0x40208000) /lib/libc.so.0
_dl_get_ready_to_run:1042: Loading: (0x40208000) /lib/libc.so.0
_dl_get_ready_to_run:1042: Loading: (0x4019b000) /lib/libgcc_s.so.1
_dl_get_ready_to_run:1042: Loading: (0x40074000) /lib/ld-uClibc.so.0
_dl_get_ready_to_run:1042: Loading: (0x4030e000) /usr/lib/libcrypto.so.1.0.0
_dl_get_ready_to_run:1042: Loading: (0x401e5000) /lib/libdl.so.0
_dl_get_ready_to_run:1042: Loading: (0x40208000) /lib/libc.so.0
_dl_get_ready_to_run:1042: Loading: (0x401e5000) /lib/libdl.so.0
_dl_get_ready_to_run:1042: Loading: (0x4019b000) /lib/libgcc_s.so.1
_dl_get_ready_to_run:1042: Loading: (0x40208000) /lib/libc.so.0
_dl_get_ready_to_run:1042: Loading: (0x40208000) /lib/libc.so.0
_dl_get_ready_to_run:1042: Loading: (0x40208000) /lib/libc.so.0
_dl_get_ready_to_run:1042: Loading: (0x40074000) /lib/ld-uClibc.so.0
_dl_get_ready_to_run:1285: Beginning relocation fixups
transfering control to application @ 0x9748
Segmentation fault (core dumped)
# gdb /usr/bin/curl -c /root/core
ELF header=0x40024000
First Dynamic section entry=0x40033ef0
Scanning DYNAMIC section
Done scanning DYNAMIC section
About to do library loader relocations
Done relocating ldso; we can now use globals and make function calls!
_dl_get_ready_to_run:454: Cool, ldso survived making function calls
_dl_malloc:246: mmapping more memory
_dl_ldsopath_init:162: Lib Loader: (0x40024000) /lib/ld-uClibc.so.0: using path: /lib
_dl_get_ready_to_run:1042: Loading: (0x40049000) /usr/lib/libncurses.so.5
_dl_get_ready_to_run:1042: Loading: (0x400ec000) /lib/libm.so.0
_dl_get_ready_to_run:1042: Loading: (0x40111000) /lib/libdl.so.0
_dl_get_ready_to_run:1042: Loading: (0x40121000) /lib/libgcc_s.so.1
_dl_get_ready_to_run:1042: Loading: (0x40134000) /lib/libc.so.0
_dl_get_ready_to_run:1042: Loading: (0x40134000) /lib/libc.so.0
_dl_get_ready_to_run:1042: Loading: (0x40134000) /lib/libc.so.0
_dl_get_ready_to_run:1042: Loading: (0x40134000) /lib/libc.so.0
_dl_get_ready_to_run:1042: Loading: (0x40024000) /lib/ld-uClibc.so.0
_dl_get_ready_to_run:1042: Loading: (0x40134000) /lib/libc.so.0
_dl_get_ready_to_run:1042: Loading: (0x40024000) /lib/ld-uClibc.so.0
_dl_get_ready_to_run:1285: Beginning relocation fixups
transfering control to application @ 0x3ffe0
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-unknown-linux-uclibcgnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/curl...done.
[New Thread 597]
Reading symbols from /usr/lib/libcurl.so.4...done.
Loaded symbols for /usr/lib/libcurl.so.4
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libc.so.0.../home/johan/buildroot/output/toolchain/gdb-7.1a/gdb/utils.c:1246: internal-error: virtual
memory exhausted: can't allocate 59954836 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n
/home/johan/buildroot/output/toolchain/gdb-7.1a/gdb/utils.c:1246: internal-error: virtual memory exhausted: can't allocate 59954836
bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
#
-----Oorspronkelijk bericht-----
Van: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] Namens Thomas Petazzoni
Verzonden: donderdag 15 maart 2012 8:00
Aan: Sagaert Johan
CC: buildroot at uclibc.org
Onderwerp: Re: [Buildroot] core file
Hello,
Please keep the Buildroot list in the loop.
Le Thu, 15 Mar 2012 03:02:29 +0100,
"Sagaert Johan" <sagaert.johan@skynet.be> a ?crit :
> I have the core file and gdb on the target.
>
> What should i do with it, i never used gdb on the command line so far.
If you have gdb on the target, then:
gdb /usr/bin/curl -c /path/to/the/core/file
By the way, if you are using BR2_CCACHE, then please disable it and do a complete rebuild to see if it works better.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux development, consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] core file
2012-03-15 12:17 ` Sagaert Johan
@ 2012-03-15 13:19 ` Thomas Petazzoni
2012-03-15 14:36 ` Sagaert Johan
2012-03-15 22:46 ` Arnout Vandecappelle
0 siblings, 2 replies; 6+ messages in thread
From: Thomas Petazzoni @ 2012-03-15 13:19 UTC (permalink / raw)
To: buildroot
Le Thu, 15 Mar 2012 13:17:06 +0100,
"Sagaert Johan" <sagaert.johan@skynet.be> a ?crit :
> # curl
> ELF header=0x40074000
> First Dynamic section entry=0x40083ef0
> Scanning DYNAMIC section
> Done scanning DYNAMIC section
Seeing those messages, seems like you have built your uClibc with too
many debugging options.
> Reading symbols from /lib/libc.so.0.../home/johan/buildroot/output/toolchain/gdb-7.1a/gdb/utils.c:1246: internal-error: virtual
> memory exhausted: can't allocate 59954836 bytes.
And you have built it with debugging symbols it seems, so its size is
way too big to load on your target. Either use cross-gdb+gdbserver, or
don't compile the uClibc with debugging symbols.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] core file
2012-03-15 13:19 ` Thomas Petazzoni
@ 2012-03-15 14:36 ` Sagaert Johan
2012-03-15 15:52 ` Thomas Petazzoni
2012-03-15 22:46 ` Arnout Vandecappelle
1 sibling, 1 reply; 6+ messages in thread
From: Sagaert Johan @ 2012-03-15 14:36 UTC (permalink / raw)
To: buildroot
Hi
This is the result from a run with no debug symbols
Also tested using ARM926t instead of the Generic Arm, but this makes no difference. (arm926t = Thumb ?)
Since libdl is the last one, could this one be the one causing the segfault ?
# gdb /usr/bin/curl -c /root/core
GNU gdb (GDB) 7.1
[New Thread 600]
Reading symbols from /usr/lib/libcurl.so.4...(no debugging symbols found)...done
.
Loaded symbols for /usr/lib/libcurl.so.4
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libc.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.0
Reading symbols from /usr/lib/libssl.so.1.0.0...(no debugging symbols found)...d
one.
Loaded symbols for /usr/lib/libssl.so.1.0.0
Reading symbols from /usr/lib/libcrypto.so.1.0.0...(no debugging symbols found).
..done.
Loaded symbols for /usr/lib/libcrypto.so.1.0.0
Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/ld-uClibc.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-uClibc.so.0
Reading symbols from /lib/libdl.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.0
Core was generated by `curl'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000000 in ?? ()
(gdb)
-----Oorspronkelijk bericht-----
Van: buildroot-bounces at busybox.net [mailto:buildroot-bounces at busybox.net] Namens Thomas Petazzoni
Verzonden: donderdag 15 maart 2012 14:19
Aan: Sagaert Johan
CC: buildroot at busybox.net
Onderwerp: Re: [Buildroot] core file
Le Thu, 15 Mar 2012 13:17:06 +0100,
"Sagaert Johan" <sagaert.johan@skynet.be> a ?crit :
> # curl
> ELF header=0x40074000
> First Dynamic section entry=0x40083ef0 Scanning DYNAMIC section Done
> scanning DYNAMIC section
Seeing those messages, seems like you have built your uClibc with too many debugging options.
> Reading symbols from
> /lib/libc.so.0.../home/johan/buildroot/output/toolchain/gdb-7.1a/gdb/utils.c:1246: internal-error: virtual memory exhausted: can't
allocate 59954836 bytes.
And you have built it with debugging symbols it seems, so its size is way too big to load on your target. Either use
cross-gdb+gdbserver, or don't compile the uClibc with debugging symbols.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux development, consulting, training and support.
http://free-electrons.com
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] core file
2012-03-15 14:36 ` Sagaert Johan
@ 2012-03-15 15:52 ` Thomas Petazzoni
0 siblings, 0 replies; 6+ messages in thread
From: Thomas Petazzoni @ 2012-03-15 15:52 UTC (permalink / raw)
To: buildroot
Le Thu, 15 Mar 2012 15:36:35 +0100,
"Sagaert Johan" <sagaert.johan@skynet.be> a ?crit :
> This is the result from a run with no debug symbols
Yeah, but then it's useless. You should build curl and libcurl with
debugging symbols, and the C library without. But it's unfortunately
not easy to do with Buildroot.
> Also tested using ARM926t instead of the Generic Arm, but this makes no difference. (arm926t = Thumb ?)
The T is to say that Thumb is supported, but unless you specify -mthumb
in the flags, it's still ARM code that gets generated.
> Since libdl is the last one, could this one be the one causing the segfault ?
No, it's just the last shared library that gets loaded, nothing to do
with the reason of the crash.
> Core was generated by `curl'.
> Program terminated with signal 11, Segmentation fault.
> #0 0x00000000 in ?? ()
So it crashes that early? Strange.
Can you put your root filesystem image somewhere online?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] core file
2012-03-15 13:19 ` Thomas Petazzoni
2012-03-15 14:36 ` Sagaert Johan
@ 2012-03-15 22:46 ` Arnout Vandecappelle
1 sibling, 0 replies; 6+ messages in thread
From: Arnout Vandecappelle @ 2012-03-15 22:46 UTC (permalink / raw)
To: buildroot
On Thursday 15 March 2012 14:19:29 Thomas Petazzoni wrote:
> And you have built it with debugging symbols it seems, so its size is
> way too big to load on your target. Either use cross-gdb+gdbserver, or
> don't compile the uClibc with debugging symbols.
cross-gdb with or without gdbserver is really the way to go. Then you
don't need to compile with debug symbols. But I guess Johan would like
to get some explanation how to do that.
Without gdbserver:
On the target, enable core files with 'ulimit -c 0' and run curl.
You should get a core file in the current directory.
Copy the core file to the build host.
Go to the source directory of curl. Run
../../host/usr/bin/arm*gdb src/curl <corefile>
Now you can look at the backtrace in the debugger, it shows the
source as well.
With gdbserver:
On the target, run
gdbserver any:8888 curl
On the host, run gdb in the curl source directory like above.
../../host/usr/bin/arm*gdb src/curl
gdb> set target <ipaddr>:8888
gdb> continue
Now the program runs up to the segmentation fault.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-03-15 22:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <DC8F7388218A402C9FEADA4D9CC577B3@JohanW7>
2012-03-15 7:00 ` [Buildroot] core file Thomas Petazzoni
2012-03-15 12:17 ` Sagaert Johan
2012-03-15 13:19 ` Thomas Petazzoni
2012-03-15 14:36 ` Sagaert Johan
2012-03-15 15:52 ` Thomas Petazzoni
2012-03-15 22:46 ` Arnout Vandecappelle
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox