Re: 1.5.18: ld command generates stackdump
CGF It is useless. You probaby have to continue CGF after ld has been attached to see where the CGF SEGV really is coming from. Thanks. Here is the result... GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special) Copyright 2004 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 i686-pc-cygwin... Attaching to program `/bin/ld.exe', process 4060 [Switching to thread 4060.0x9f8] (gdb) bt #0 0x7c901231 in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c9507a8 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x0005 in ?? () #3 0x0004 in ?? () #4 0x0001 in ?? () #5 0x195dffd0 in ?? () #6 0x867810e8 in ?? () #7 0x in ?? () #8 0x7c90ee18 in strchr () from /cygdrive/c/WINDOWS/system32/ntdll.dll #9 0x7c9507c8 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll #10 0x in ?? () from (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to thread 4060.0xf60] 0x610c4914 in memcpy () from /bin/cygwin1.dll (gdb) bt #0 0x610c4914 in memcpy () from /bin/cygwin1.dll #1 0x6100275e in toascii () from /bin/cygwin1.dll #2 0x61050c8e in lsearch () from /bin/cygwin1.dll #3 0x610516e4 in lsearch () from /bin/cygwin1.dll #4 0x61051f79 in lsearch () from /bin/cygwin1.dll #5 0x610ab36c in setstate () from /bin/cygwin1.dll #6 0x6104ed0a in lsearch () from /bin/cygwin1.dll #7 0x610844ff in cygwin1!aclcheck () from /bin/cygwin1.dll #8 0x00428f50 in bfd_alloc (abfd=0x2c9aa418, size=320) at opncls.c:853 #9 0x00428f9e in bfd_zalloc (abfd=0x2c9aa418, size=320) at opncls.c:876 #10 0x00432e77 in coff_new_section_hook (abfd=0x2c9aa418, section=0x2c9fb7a0) at coffcode.h:1569 #11 0x0042288c in bfd_section_init (abfd=0x2c9aa418, newsect=0x2c9fb7a0) at section.c:773 #12 0x00422cee in bfd_make_section_anyway (abfd=0x2c9aa418, name=0x2c9fd8b8 .rdata$_ZTV15TCMapProjection) at section.c:1084 #13 0x0042f375 in coff_object_p (abfd=0x2c9aa418) at coffgen.c:99 #14 0x004284a7 in bfd_check_format_matches (abfd=0x2c9aa418, format=bfd_object, matching=0x0) at format.c:167 #15 0x0042857e in bfd_check_format (abfd=0x2c9aa418, format=bfd_object) at format.c:91 #16 0x004239ba in _bfd_generic_link_add_archive_symbols (abfd=0x2c538620, info=0x4af0c0, checkfn=0x4455b0 coff_link_check_archive_element) at linker.c:1085 #17 0x00445566 in _bfd_coff_link_add_symbols (abfd=0x2c538620, info=incomplete type) at cofflink.c:166 #18 0x00409be4 in load_symbols (entry=0x2c538620, place=0x1) at ldlang.c:2275 #19 0x0040a5ed in open_input_bfds (s=0x4af0c0, force=1) at ldlang.c:2685 #20 0x0040f3a2 in lang_process () at ldlang.c:5288 #21 0x00411765 in main (argc=153, argv=0x61156a48) at .././ld/ldmain.c:460 (gdb) Now we're getting somewhere. TCMapProjection is a class in one of my libraries. What next? Sorry for being a pest. Pete -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
One last post before calling it a night. I built a debug version of the
cygwin DLL as well and installed it. Here is the latest gdb session:
Attaching to program `/bin/ld.exe', process 304
[Switching to thread 304.0x990]
(gdb) bt
#0 0x7c901231 in ntdll!DbgUiConnectToDbg ()
from /cygdrive/c/WINDOWS/system32/ntdll.dll
#1 0x7c9507a8 in ntdll!KiIntSystemCall ()
from /cygdrive/c/WINDOWS/system32/ntdll.dll
#2 0x0005 in ?? ()
#3 0x0004 in ?? ()
#4 0x0001 in ?? ()
#5 0x195dffd0 in ?? ()
#6 0x862a0968 in ?? ()
#7 0x in ?? ()
#8 0x7c90ee18 in strchr () from /cygdrive/c/WINDOWS/system32/ntdll.dll
#9 0x7c9507c8 in ntdll!KiIntSystemCall ()
from /cygdrive/c/WINDOWS/system32/ntdll.dll
#10 0x in ?? () from
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 304.0x76c]
0x610c4914 in memcpy ()
at ../../../../cygwin-1.5.18-1/winsup/cygserver/client.cc:464
464 syscall_printf (cygserver un-available);
Current language: auto; currently c++
(gdb) bt
#0 0x610c4914 in memcpy ()
at ../../../../cygwin-1.5.18-1/winsup/cygserver/client.cc:464
#1 0x6100275e in crealloc (s=0x611ad488, n=262360)
at ../../../../cygwin-1.5.18-1/winsup/cygwin/cygheap.cc:242
#2 0x61050c8e in list::add_record (this=0x61159870, r=
{fdesc_ = -1, mapping_handle_ = 0x4a3c, access_mode_ = 1, flags_
= 34, o
ffset_ = 0, size_to_map_ = 8192, base_address_ = 0x2c9fe000 ,
page_map_ = 0x0,
dev = {name = 0x2000 Address 0x2000 out of bounds, {devn = 0, {minor
= 0, maj
or = 0}}, native = 0x22 Address 0x22 out of bounds, mode = 4294967295,
dev_on_
fs = false}}, off=0, len=8192)
at ../../../../cygwin-1.5.18-1/winsup/cygwin/mmap.cc:375
#3 0x610516e4 in mmap64 (addr=0x0, len=8192, prot=1, flags=34, fd=-1,
off=0)
at ../../../../cygwin-1.5.18-1/winsup/cygwin/mmap.cc:749
#4 0x61051f79 in mmap (addr=0x0, len=8192, prot=3, flags=34, fd=-1,
off=0)
at ../../../../cygwin-1.5.18-1/winsup/cygwin/mmap.cc:768
#5 0x610ab36c in dlmalloc (bytes=0)
at ../../../../cygwin-1.5.18-1/winsup/cygwin/malloc.cc:3341
#6 0x6104ed0a in malloc (size=4064)
at ../../../../cygwin-1.5.18-1/winsup/cygwin/malloc_wrapper.cc:69
#7 0x610844ff in _sigfe ()
at ../../../../cygwin-1.5.18-1/winsup/cygwin/cygserver.h:82
#8 0x0022e968 in ?? ()
#9 0x004227f9 in bfd_section_hash_newfunc (entry=0x2c9aa4d8,
table=incomplete type, string=0x22e9a8 Oé\) at section.c:738
#10 0x00428f50 in bfd_alloc (abfd=0x2c9aa418, size=320) at opncls.c:853
#11 0x00428f9e in bfd_zalloc (abfd=0x2c9aa418, size=320) at opncls.c:876
#12 0x00432e77 in coff_new_section_hook (abfd=0x2c9aa418,
section=0x2c9fb7a0)
at coffcode.h:1569
#13 0x0042288c in bfd_section_init (abfd=0x2c9aa418, newsect=0x2c9fb7a0)
at section.c:773
#14 0x00422cee in bfd_make_section_anyway (abfd=0x2c9aa418,
name=0x2c9fd8b8 .rdata$_ZTV15TCMapProjection) at section.c:1084
#15 0x0042f375 in coff_object_p (abfd=0x2c9aa418) at coffgen.c:99
#16 0x004284a7 in bfd_check_format_matches (abfd=0x2c9aa418,
format=bfd_object, matching=0x0) at format.c:167
#17 0x0042857e in bfd_check_format (abfd=0x2c9aa418, format=bfd_object)
at format.c:91
#18 0x004239ba in _bfd_generic_link_add_archive_symbols
(abfd=0x2c538620,
info=0x4af0c0, checkfn=0x4455b0 coff_link_check_archive_element)
at linker.c:1085
#19 0x00445566 in _bfd_coff_link_add_symbols (abfd=0x2c538620,
info=incomplete type) at cofflink.c:166
#20 0x00409be4 in load_symbols (entry=0x2c538620, place=0x1) at
ldlang.c:2275
#21 0x0040a5ed in open_input_bfds (s=0x4af0c0, force=1) at ldlang.c:2685
#22 0x0040f3a2 in lang_process () at ldlang.c:5288
#23 0x00411765 in main (argc=153, argv=0x61156a48) at
.././ld/ldmain.c:460
(gdb)
Looks like it is craching on
464 syscall_printf (cygserver un-available);
in memcpy. Make any sense?
Will check the list tomorrow. TIA.
Pete
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
On Thu, Oct 13, 2005 at 11:50:45PM -0700, Peter J. Stieber wrote: One last post before calling it a night. I built a debug version of the cygwin DLL as well and installed it. Here is the latest gdb session: I don't remember if I suggested trying a snapshot but I'm wondering if a snapshot would just fix your problem: http://cygwin.com/snapshots/ . cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
PS = Peter J. Stieber PSOne last post before calling it a night. I built a debug PS version of the cygwin DLL as well and installed it. PS Here is the latest gdb session: CGF I don't remember if I suggested trying a snapshot CGF but I'm wondering if a snapshot would just fix CGF your problem: http://cygwin.com/snapshots/ . Tried 20051013 and it worked :-))) I will let my development crew know when the next version of the cygwin DLL is released. Thanks again Christopher and Brian for the help. And as always, thanks to Corinna, Christopher, Igor, Joshua, and the many others to numerous to mention for all of their hard work on cygwin. Do I get a gold star ;-) Pete -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
On Fri, Oct 14, 2005 at 10:15:36AM -0700, Peter J. Stieber wrote: PS = Peter J. Stieber PSOne last post before calling it a night. I built a debug PS version of the cygwin DLL as well and installed it. PS Here is the latest gdb session: CGF I don't remember if I suggested trying a snapshot CGF but I'm wondering if a snapshot would just fix CGF your problem: http://cygwin.com/snapshots/ . Tried 20051013 and it worked :-))) I'm sorry that it didn't occur to me much earlier that this was a cygwin heap problem that was fixed in a snapshot. I guess that, as a rule of thumb, try a snapshot is always a good idea. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
PSTried 20051013 and it worked :-))) CGF I'm sorry that it didn't occur to me much CGF earlier that this was a cygwin CGF heap problem that was fixed in a snapshot. CGF I guess that, as a rule of thumb, CGF try a snapshot is always a good idea. Not to be a total brown nose, but I've been using cygwin for a long time and this is only the second time I've had to resort to a snapshot to solve a problem. In other words cygwin is normally stable enough so I don't think to try a snapshot. I should have tried it before posting. At least I learned how to build a debug version of the binutils package on cygwin. Thanks again, and I forgot to thank René Berber for his input, Pete -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
PS = Peter J. Stieber on 10/9/2005 7:59 PM: PS It's attached. I added the -t command to the g++ command so PS the loader would list the files it was processing when it breaks. PS The name of the object file in the last line should be PS SimpleInterpolationTable.o, but it gets truncated. PS (/home/pete/Build/lib/libUtilityg.a)SimpleInterpolmake: *** [slamem.exe] PS Error 1 You may be hitting command line length limitations. I'm wondering if the core dump happens because the truncated argument was not NUL-terminated. Have you considered bundling arguments into a temporary file, then passing @filename as the lone argument to ld, to bypass the command-line length limitations? You may also want to try mounting ld's directory as cygexec, or trying a recent snapshot, both of which use cygwin magic to increase the command-line length of cygwin applications. CF = Christopher Faylor CF This seems like a real shot in the dark to me. CF What would not be terminating a truncated CF command line? Cygwin? That's not likely. CF CF AFAIK, only very recent CVS versions of CF binutils take '@' command line arguments, CF although cygwin will honor them itself for CF processes which are not started by a cygwin CF process. I don't see any indication that CF this is the problem here. CF CF If this is a command-line length problem then something like: CF CF mount -X -b c:/cygwin/bin /bin CF mount -X -b c:/cygwin/bin /usr/bin CF CFwould probably fix it. CF CF See: http://cygwin.com/faq/faq-nochunks.html#faq.programming.make-execvp I tried this, but I am still seeing the problem. Calling the mount comment results in the following: CF Btw, if the above doesn't fix this and you can't provide CF any more details then it seems like your best bet would CF be to build a debugging version of binutils and see where CF the core dump is coming from. CF CF If you include error_start:c:/cygwin/bin/gdb.exe in CF your CYGWIN environment variable, it will start gdb CF automatically when a SEGV is encountered. Sorry in advance for the stupid questions, but... I downloaded the binutils source package, and extracted the source. When I ran ./configure --help I didn't see a --enable-debug option or anything I though was equivalent. Am I missing something? Do I also need to build a debug version of the cygwin DLL? Pete -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
Peter J. Stieber wrote: Sorry in advance for the stupid questions, but... I downloaded the binutils source package, and extracted the source. When I ran ./configure --help I didn't see a --enable-debug option or anything I though was equivalent. Am I missing something? Normally, auto-tooled packages like binutils have a default value for CFLAGS that is typically -g -O2 which means you get the debug information. When creating binary packages for distribution the binaries are typically stripped later. This is just a long-winded way of saying that if you build with the default configure options you should get debug information, and if not use a CFLAGS override when calling configure. Do I also need to build a debug version of the cygwin DLL? It would help, since otherwise backtraces will only have raw addresses. Note that the cygwin configure script[*] has a --enable-debugging switch, but this is for enabling lots of runtime consistency checks and extra verbosity -- it is not meant for enabling debug symbols, which you should get by default. [*] It's not in the toplevel configure, so it won't show up if you do --help from there. But if you --help in the winsup/cygwin directory it will show up, and you can still specify it at the top level where it will be passed along. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
On Thu, Oct 13, 2005 at 04:39:13PM -0700, Brian Dessent wrote: Peter J. Stieber wrote: Sorry in advance for the stupid questions, but... I downloaded the binutils source package, and extracted the source. When I ran ./configure --help I didn't see a --enable-debug option or anything I though was equivalent. Am I missing something? Normally, auto-tooled packages like binutils have a default value for CFLAGS that is typically -g -O2 which means you get the debug information. When creating binary packages for distribution the binaries are typically stripped later. This is just a long-winded way of saying that if you build with the default configure options you should get debug information, and if not use a CFLAGS override when calling configure. Do I also need to build a debug version of the cygwin DLL? It would help, since otherwise backtraces will only have raw addresses. Note that the cygwin configure script[*] has a --enable-debugging switch, but this is for enabling lots of runtime consistency checks and extra verbosity -- it is not meant for enabling debug symbols, which you should get by default. Is this dying in the cygwin DLL? I suspect that it isn't. The stackdump file would show if it is, as would using CYGWIN error_start setting that I mentioned previously. I don't think there's any reason to build a debugging version of cygwin unless the problem points to the cygwin DLL. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
PS = Peter J. Stieber PS Sorry in advance for the stupid questions, but... PS PS I downloaded the binutils source package, and PS extracted the source. When PS I ran PS PS ./configure --help PS PS I didn't see a --enable-debug option or anything PS I though was equivalent. Am I missing something? BD = Brian Dessent BD Normally, auto-tooled packages like binutils have a BD default value for CFLAGS that is typically -g -O2 BD which means you get the debug information. When BD creating binary packages for distribution the BD binaries are typically stripped later. Thanks for the info Brian. I ran ./configure successfully in the extracted binutils-20050610-1 directory. When I ran make I ran into the following error: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -o ar.exe arparse.o arlex.o ar.o not-ranlib.o arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o ../bfd/.libs/libbfd.a ../libiberty/libiberty.a ./../intl/libintl.a arlex.o: In function `main': /home/pete/binutils-20050610-1/binutils/arlex.c:1: multiple definition of `_main' arparse.o:/home/pete/binutils-20050610-1/binutils/arparse.c:1: first defined here ar.o: In function `main': /home/pete/binutils-20050610-1/binutils/ar.c:337: multiple definition of `_main' arparse.o:/home/pete/binutils-20050610-1/binutils/arparse.c:1: first defined here ar.o: In function `mri_emul': /home/pete/binutils-20050610-1/binutils/ar.c:143: undefined reference to `_yyparse' collect2: ld returned 1 exit status make[3]: *** [ar.exe] Error 1 make[3]: Leaving directory `/home/pete/binutils-20050610-1/binutils' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/pete/binutils-20050610-1/binutils' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/pete/binutils-20050610-1/binutils' I'm not quite sure what the problem is. I have bison, flex and byacc loaded. Sorry for being a naive pest, Pete -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
PS = Pete Stieber PS Do I also need to build a debug version of the cygwin DLL? BD = Brian Dessent BDIt would help, since otherwise backtraces will only have raw BD addresses. Note that the cygwin configure script[*] has a BD --enable-debugging switch, but this is for enabling lots of BD runtime consistency checks and extra verbosity -- it is not BD meant for enabling debug symbols, which you BDshould get by default. CF Is this dying in the cygwin DLL? I suspect that it isn't. CF The stackdump file would show if it is, as would using CF CYGWIN error_start setting that I mentioned previously. CF CF I don't think there's any reason to build a debugging CF version of cygwin unless the problem points to the CF cygwin DLL. Keeping in mind that I am having problems building binutils (mentioned in a recent reply to Brian's post), here is the back trace from a stripped version of ld using the technique you suggested. Attaching to program `/bin/ld.exe', process 3248 [Switching to thread 3248.0x850] (gdb) bt #0 0x7c901231 in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c9507a8 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x0005 in ?? () #3 0x0004 in ?? () #4 0x0001 in ?? () #5 0x1941ffd0 in ?? () #6 0x3531283a in ?? () #7 0x in ?? () #8 0x7c90ee18 in strchr () from /cygdrive/c/WINDOWS/system32/ntdll.dll #9 0x7c9507c8 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll #10 0x in ?? () from (gdb) This is probably useless, but just wanted to indicate I'm not ignoring your advice. It is greatly appreciated. Thanks for the help Christopher, Pete -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
PS = Peter J. Stieber PS Sorry in advance for the stupid questions, but... PS PS I downloaded the binutils source package, and PS extracted the source. When PS I ran PS PS ./configure --help PS PS I didn't see a --enable-debug option or anything PS I though was equivalent. Am I missing something? BD = Brian Dessent BD Normally, auto-tooled packages like binutils have a BD default value for CFLAGS that is typically -g -O2 BD which means you get the debug information. When BD creating binary packages for distribution the BD binaries are typically stripped later. PS Thanks for the info Brian. I ran ./configure successfully PS in the extracted binutils-20050610-1 directory. When PS I ran make I ran into the following error: A bunch removed. PS I'm not quite sure what the problem is. I have bison, PS flex and byacc loaded. Actually I loaded them after the error. After I removed the build directory and started over the code is building fine now. I will send the backtrace for my particular ld problem when I am through. BTW I have successfully built other codes with the same ld. I'm just getting a ld crash with one particular code. I guess that's obvious considering I'm building binutils with the same ld command. Thanks to all of the cygwin developers for their efforts, Pete -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
1. I built the binutils code from the source. 2. I renamed /usr/bin/ld.exe to /usr/bin/ld-old.exe. 3. I copies ld-new.exe to /usr/bin. The debug session that starts when ld crashes repeats Program received signal SIGSEGV, Segmentation fault. over and over. It never seems to stop. Was copying ld-new.exe to /usr/bin/ld.exe the correct thing to do. I was afraid make install might strip the executable. Pete -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
On Thu, Oct 13, 2005 at 09:35:06PM -0700, Peter J. Stieber wrote: PS = Pete Stieber PS Do I also need to build a debug version of the cygwin DLL? BD = Brian Dessent BDIt would help, since otherwise backtraces will only have raw BD addresses. Note that the cygwin configure script[*] has a BD --enable-debugging switch, but this is for enabling lots of BD runtime consistency checks and extra verbosity -- it is not BD meant for enabling debug symbols, which you BDshould get by default. CF Is this dying in the cygwin DLL? I suspect that it isn't. CF The stackdump file would show if it is, as would using CF CYGWIN error_start setting that I mentioned previously. CF CF I don't think there's any reason to build a debugging CF version of cygwin unless the problem points to the CF cygwin DLL. Keeping in mind that I am having problems building binutils (mentioned in a recent reply to Brian's post), here is the back trace from a stripped version of ld using the technique you suggested. Attaching to program `/bin/ld.exe', process 3248 [Switching to thread 3248.0x850] (gdb) bt #0 0x7c901231 in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c9507a8 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x0005 in ?? () #3 0x0004 in ?? () #4 0x0001 in ?? () #5 0x1941ffd0 in ?? () #6 0x3531283a in ?? () #7 0x in ?? () #8 0x7c90ee18 in strchr () from /cygdrive/c/WINDOWS/system32/ntdll.dll #9 0x7c9507c8 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll #10 0x in ?? () from (gdb) This is probably useless, but just wanted to indicate I'm not ignoring your advice. It is greatly appreciated. It is useless. You probaby have to continue after ld has been attached to see where the SEGV really is coming from. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
On Thu, Oct 13, 2005 at 10:33:46PM -0700, Peter J. Stieber wrote: 1. I built the binutils code from the source. 2. I renamed /usr/bin/ld.exe to /usr/bin/ld-old.exe. 3. I copies ld-new.exe to /usr/bin. The debug session that starts when ld crashes repeats Program received signal SIGSEGV, Segmentation fault. over and over. It never seems to stop. It does stop eventually. Or, you could type 'q' and then 'continue'. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
OK. This time gdb seemed to attach to the broken ld process, but the back trace still doesn't have symbols... GNU gdb 6.3.50_2004-12-28-cvs (cygwin-special) Copyright 2004 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 i686-pc-cygwin... Attaching to program `/bin/ld.exe', process 3028 [Switching to thread 3028.0x604] (gdb) bt #0 0x7c901231 in ntdll!DbgUiConnectToDbg () from /cygdrive/c/WINDOWS/system32/ntdll.dll #1 0x7c9507a8 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll #2 0x0005 in ?? () #3 0x0004 in ?? () #4 0x0001 in ?? () #5 0x195dffd0 in ?? () #6 0x74617453 in ?? () #7 0x in ?? () #8 0x7c90ee18 in strchr () from /cygdrive/c/WINDOWS/system32/ntdll.dll #9 0x7c9507c8 in ntdll!KiIntSystemCall () from /cygdrive/c/WINDOWS/system32/ntdll.dll #10 0x in ?? () from (gdb) Any suggestions? It looks like my new version of ld is in /bin and /usr/bin. Pete -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Peter J. Stieber on 10/9/2005 7:59 PM: It's attached. I added the -t command to the g++ command so the loader would list the files it was processing when it breaks. The name of the object file in the last line should be SimpleInterpolationTable.o, but it gets truncated. (/home/pete/Build/lib/libUtilityg.a)SimpleInterpolmake: *** [slamem.exe] Error 1 You may be hitting command line length limitations. I'm wondering if the core dump happens because the truncated argument was not NUL-terminated. Have you considered bundling arguments into a temporary file, then passing @filename as the lone argument to ld, to bypass the command-line length limitations? You may also want to try mounting ld's directory as cygexec, or trying a recent snapshot, both of which use cygwin magic to increase the command-line length of cygwin applications. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDSlrb84KuGfSFAYARAkrWAJ9qZ0dF31O4N1jjXv8k683REdnQfwCgv0Z/ UfYLX90tEDM87fyFdHL25po= =BqfA -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
On Mon, Oct 10, 2005 at 06:13:15AM -0600, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Peter J. Stieber on 10/9/2005 7:59 PM: It's attached. I added the -t command to the g++ command so the loader would list the files it was processing when it breaks. The name of the object file in the last line should be SimpleInterpolationTable.o, but it gets truncated. (/home/pete/Build/lib/libUtilityg.a)SimpleInterpolmake: *** [slamem.exe] Error 1 You may be hitting command line length limitations. I'm wondering if the core dump happens because the truncated argument was not NUL-terminated. Have you considered bundling arguments into a temporary file, then passing @filename as the lone argument to ld, to bypass the command-line length limitations? You may also want to try mounting ld's directory as cygexec, or trying a recent snapshot, both of which use cygwin magic to increase the command-line length of cygwin applications. This seems like a real shot in the dark to me. What would not be terminating a truncated command line? Cygwin? That's not likely. AFAIK, only very recent CVS versions of binutils take '@' command line arguments, although cygwin will honor them itself for processes which are not started by a cygwin process. I don't see any indication that this is the problem here. If this is a command-line length problem then something like: mount -X -b c:/cygwin/bin /bin mount -X -b c:/cygwin/bin /usr/bin would probably fix it. See: http://cygwin.com/faq/faq-nochunks.html#faq.programming.make-execvp cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
On Mon, Oct 10, 2005 at 11:18:06AM -0400, Christopher Faylor wrote: On Mon, Oct 10, 2005 at 06:13:15AM -0600, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Peter J. Stieber on 10/9/2005 7:59 PM: It's attached. I added the -t command to the g++ command so the loader would list the files it was processing when it breaks. The name of the object file in the last line should be SimpleInterpolationTable.o, but it gets truncated. (/home/pete/Build/lib/libUtilityg.a)SimpleInterpolmake: *** [slamem.exe] Error 1 You may be hitting command line length limitations. I'm wondering if the core dump happens because the truncated argument was not NUL-terminated. Have you considered bundling arguments into a temporary file, then passing @filename as the lone argument to ld, to bypass the command-line length limitations? You may also want to try mounting ld's directory as cygexec, or trying a recent snapshot, both of which use cygwin magic to increase the command-line length of cygwin applications. This seems like a real shot in the dark to me. What would not be terminating a truncated command line? Cygwin? That's not likely. AFAIK, only very recent CVS versions of binutils take '@' command line arguments, although cygwin will honor them itself for processes which are not started by a cygwin process. I don't see any indication that this is the problem here. If this is a command-line length problem then something like: mount -X -b c:/cygwin/bin /bin mount -X -b c:/cygwin/bin /usr/bin would probably fix it. See: http://cygwin.com/faq/faq-nochunks.html#faq.programming.make-execvp Btw, if the above doesn't fix this and you can't provide any more details then it seems like your best bet would be to build a debugging version of binutils and see where the core dump is coming from. If you include error_start:c:/cygwin/bin/gdb.exe in your CYGWIN environment variable, it will start gdb automatically when a SEGV is encountered. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
Peter J. Stieber wrote: I have a large simluation that I have built under cygwin for a quite a while. Recently the ld phase of the build started generating a stackdump (ld.exe.stackdump). Unfortunately I cannot recreate the problem with a simple test case. I have attached cygcheck output. I realize I'm not providing much information, but I am not sure what to do next. Would the stackdump be of use? No, but the actual command line that caused the failure could be interesting, i.e. which libraries are being linked. Any other error/waring messages before the failure? What should I do or provide to get some help? Do you use any 3rd party packages? I mean any libraries that don't come with Cygwin. Have you tried to do only the linking by hand? -- René Berber -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.18: ld command generates stackdump
PS = Peter J. Stieber PS I have a large simluation that I have built under cygwin for a PS quite a while. Recently the ld phase of the build started PS generating a stackdump (ld.exe.stackdump). PS PS Unfortunately I cannot recreate the problem with a simple PS test case. I have attached cygcheck output. I realize PS I'm not providing much information, but I am not PS sure what to do next. PS PS Would the stackdump be of use? RB = René Berber RB No, but the actual command line that caused the RB failure could be interesting, i.e. which libraries RB are being linked. It's attached. I added the -t command to the g++ command so the loader would list the files it was processing when it breaks. The name of the object file in the last line should be SimpleInterpolationTable.o, but it gets truncated. RB Any other error/waring messages before the failure? There is a line in the output file indicating ld broke. collect2: ld terminated with signal 11 [Segmentation fault], core dumped PS What should I do or provide to get some help? RB Do you use any 3rd party packages? RB I mean any libraries that don't come with RB Cygwin. I use wxWidgets (http://wxwidgets.org/) version 2.6.1. I build the MSW version of the library under cygwin myself. I have been doing this for a few years. I use the Matrix Template Library (http://www.osl.iu.edu/research/mtl/). This library consists of templates in headers, so you do not generate a library to link with. I recently had to modify the MTL due to a conflict with the Cygwin version of the Windows headers. A preprocessor directive (PACKED) was added that conflicted with an enumeration in the MTL. I renames all instances of the enumeration to ePACKED in the MTL to avoid conflicts. RB Have you tried to do only the linking by hand? Yes. I manually typed the g++ line in the attached output file. It broke as well. Thanks for trying to help René. Any other suggestions? Pete g++ -g -O0 -DNOMINMAX -I/usr/local/wx261/lib/wx/include/msw-ansi-release-static-2.6 -I/usr/local/wx261/include/wx-2.6 -D__WIN95__ -D__WXMSW__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -Wall -Wno-unknown-pragmas -Wno-format-y2k -t -o slamem.exe AboutDialog.o AttackNominatorDialogWx.o NetManagerData.o NodePropertiesPanel.o LinkPropertiesPanel.o RadioPropertiesPanel.o StatisticsPanel.o NetworkManagerDialog.o PauseEditor.o PauseEditor_wdr.o PauseEvents.o RetaskRequestDialogWx.o RunRateEditor.o RunRateEditor_wdr.o SlamemApp.o SlamemDocument.o SlamemMainFrame.o SlamemMapWindow.o SlamemMdiChildFrame.o SlamemTreeControl.o SlamemView.o SlamemVisualizationOptions.o ToolsTreeControl.o VisualizationDialog.o SlamAppWx_resources.o ../Slamem/libSlamemg.a ../Architecture/libArchitectureg.a ../CulturalFeatures/libCulturalFeaturesg.a ../MAM/libMAMg.a ../Asset/libAssetg.a ../AssetManager/libAssetManagerg.a ../Targeting/libTargetingg.a ../GVS/Targets/libGvsTargetsg.a ../Targets/libTargetsg.a ../Attack/libAttackg.a ../FusionAndTracking/libFusionAndTrackingg.a ../Exploitation/libExploitationg.a ../DisAmbassador/libDisAmbassadorg.a ../DttAmbassador/libDttAmbassadorg.a ../RFTags/libRFTagsg.a ../KeepoutDB/libKeepOutg.a ../Logger/libLoggerg.a ../Sensor/libSensorg.a ../SUO/libSUOg.a ../OpticalDegradation/libOpticalDegradationg.a ../Communications/libCommunicationsg.a ../Interactive/libInteractiveg.a ../Gccs/libGCCSg.a ../ServerSingleton/libServerSingletong.a -lAfrlNrtTdfg -lAntennag -lTrackingg -lClassMatrixg -lKalmang -lParticleFilterg -lBayesg -lATRg -lUSMTFg -lMidbg -lSimObjectg -lSpritesg -lMapg -lEntropyTaskerg -lEnvironmentg -lAnalysisDatag -lAstronomicg -lTinyXmlg -lTehdAmbassadorg -lTerraing -lRoadNetworkg -lFoliageg -lTWxClg -lToolsg -lTerraing -lMapg -lMapProjectiong -lExtractiong -lDtedg -lGeoidg -lDcwg -lDfadg -lVmapg -lRoadNetworkg -lDcwg -lVmapg -lCoordinateConversiong -lLoggerUtilitiesg -lSchedulerg -lMissileg -lUtilityg -lPatterng -lDisg -lSocketg -lSgp4Sdp4g -lShpg -lColorScaleg -lProgressg -lMgrsg -L/usr/local/wx261/lib /usr/local/wx261/lib/libwx_msw_xrc-2.6.a /usr/local/wx261/lib/libwx_msw_qa-2.6.a /usr/local/wx261/lib/libwx_msw_html-2.6.a /usr/local/wx261/lib/libwx_msw_adv-2.6.a /usr/local/wx261/lib/libwx_msw_core-2.6.a /usr/local/wx261/lib/libwx_base_xml-2.6.a /usr/local/wx261/lib/libwx_base_net-2.6.a /usr/local/wx261/lib/libwx_base-2.6.a -lpng -ljpeg -ltiff -lexpat -lz -lrpcrt4 -loleaut32 -lole32 -luuid -lwinspool -lwinmm -lshell32 -lcomctl32 -lcomdlg32 -lctl3d32 -ladvapi32 -lwsock32 -lgdi32 -lkernel32 -luser32 /usr/local/wx261/lib/libwx_msw_gl-2.6.a -lopengl32 -lglu32 collect2: ld terminated with signal 11 [Segmentation fault], core dumped /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: mode i386pe /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../crt0.o AboutDialog.o AttackNominatorDialogWx.o NetManagerData.o NodePropertiesPanel.o LinkPropertiesPanel.o RadioPropertiesPanel.o StatisticsPanel.o NetworkManagerDialog.o PauseEditor.o PauseEditor_wdr.o
Re: 1.5.18: ld command generates stackdump
Peter J. Stieber wrote: [snip] Yes. I manually typed the g++ line in the attached output file. It broke as well. Thanks for trying to help René. Any other suggestions? Nothing seems out of the ordinary. Have you tried the obvious, roll back binutils to a previous version? Or any other tool/library that was changed. Not much help I know, but as I said, the linker output looks fine until it crashes. A signal 11 usually means a corrupted executable with an illegal instruction. -- René Berber -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
