* [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