From: SourceForge.net <no...@so...> - 2005-03-27 17:53:10
|
Bugs item #1170212, was opened at 2005-03-24 23:15 Message generated for change (Comment added) made by hsack You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1170212&group_id=599 Category: C-Front End Group: None Status: Open Resolution: None Priority: 7 Submitted By: Hubert Sack (hsack) >Assigned to: Erik Petrich (epetrich) Summary: Compiling SDCC from cvs checkout causes SIGSEGV Initial Comment: I can't compile SDCC from the lastest (03/24/05) snapshot under Cygwin (other environments not available to me). Running make results in SIGSEGV as make tries to compile the lib by using the compiled SDCC (no errors while it's compile) I attached the output (in a textfile) ---------------------------------------------------------------------- >Comment By: Hubert Sack (hsack) Date: 2005-03-27 19:53 Message: Logged In: YES user_id=1160854 It facilitates to hear me that the problem under XP SP2 is reproducible. If I put _schar2fs.c, float.h and limits.h in the same folder and invoke SDCC form the command line, I got the SIGSEGV too. ---------------------------------------------------------------------- Comment By: Erik Petrich (epetrich) Date: 2005-03-27 19:31 Message: Logged In: YES user_id=635249 I can reproduce the problem now using Windows XP (home edition, SP2). Not only does the SIGSEGV go away when running under gdb, but the compiler also works correctly when invoked manually from the command line (instead of using make). I'll continue looking at this. ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2005-03-27 18:51 Message: Logged In: YES user_id=1160854 Some more result: I installed Cygwin on Windows NT4 WKS SP6a and compiled the latest checkout (2.4.8 #985) completely successful. But it signals SIGSEGV when it runs either at cygwin or at native Windows XP. So something must be different at WIN XP. My question: Because SDCC uses signal handlers to clean up temporary files, it should be able to detect the reason. Is any tool available to do so (I'll add this to SDCCmain.c and recompile) ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2005-03-27 17:40 Message: Logged In: YES user_id=1160854 Some more result: I installed Cygwin on Windows NT4 WKS SP6a and compiled the latest checkout (2.4.8 #985) completely successful. But it signals SIGSEGV when it runs either at cygwin or at native Windows XP. So something must be different at WIN XP. My question: Because SDCC uses signal handlers to clean up temporary files, it should be able to detect the reason. Is any tool available to do so (I'll add this to SDCCmain.c and recompile) ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2005-03-27 14:50 Message: Logged In: YES user_id=1160854 Great idea, but: Hubert Sack@NOTEBOOK ~/files/test $ cat schar2fs ulimit -c 20000 /home/hubert/sdcc/bin/sdcc --verbose -I. --model-small -- nostdinc -c _schar2fs.c -o _schar2fs.rel Hubert Sack@NOTEBOOK ~/files/test $ schar2fs ulimit: ulimit: not available on this system sdcc: Calling preprocessor... sdcc: Generating code... Caught signal 11: SIGSEGV ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2005-03-27 14:17 Message: Logged In: NO > If I try to use the gdb to run SDCC, everything is o.k. (that's > really worse, because there is no chance to have a look "into" > SDCC at the time SIGSEGV is raised). Can you persuade Cygwin to produce core dumps (ulimit -c 20000 or similar) so you can try a post-mortem debug? ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2005-03-27 14:13 Message: Logged In: YES user_id=1160854 The attachment becomes too big with the pictures attached. If someone need the pictures of the attachment, please send a Mail - thanks ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2005-03-27 14:03 Message: Logged In: YES user_id=1160854 It's really difficult to reproduce and find the reason of the problem. I checked out the source of the latest version (2.4.8 #985) and updated my cygwin installation. I put screencopies of the cygwin setup in the attachment (folder CygwinPictures). The versions of the environment, where I'm able to reproduce the problem are: Windows XP Home Edition with SP2 (512 MB RAM) Cygwin Setup was 2.457.2.2 MINGW Runtime 3.7-1 BASH 2.05b-16 GCC 3.3.3-3 If I try to use the gdb to run SDCC, everything is o.k. (that's really worse, because there is no chance to have a look "into" SDCC at the time SIGSEGV is raised). It *not* be able to reproduce the error either using Windows NT WKS SP6a nor using Windows 2000 Professional SP4. I now will install Cygwin on my WIN2K Plattform, because Softice is installed there too. I expect something like memory allocated by save_alloc, save_realloc or a local var not being initializied. But I did *not* receive any warning compiling SDCC... I compiled a lot of versions of SDCC by checking out the sources, but I never have had any problem till 2.4.8 #980 It would help very much, if I would be able to detect the location of the access, which causes the SIGSEGV without a debugger (because I'm not able to reproduce the error there), but I don't know how at the moment. ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2005-03-27 10:03 Message: Logged In: YES user_id=888171 Hubert, Can you give us some more information? Which operating system are you running and which version of MINGW did you use to build SDCC? ---------------------------------------------------------------------- Comment By: Erik Petrich (epetrich) Date: 2005-03-27 01:47 Message: Logged In: YES user_id=635249 I just downloaded Cygwin and installed it on a Windows 2000 system. So far I've been able to successfully build 2.4.8 #285 and 2.4.8 #283, both as a Cygwin app as well as MINGW32. Since I can't reproduce this yet myself, what would be helpful is to edit the device/lib/Makefile and remove _schar2fs.c (the source file being compiled during the SIGSEGV) from the SOURCES macro and rerun the make. From your output, it appears that it successfully compiled some files, so probably it will be able to compile a few more before faulting on another. Just keep removing them from the SOURCES macro. You don't have to exhaustively test every library source file, but it would be helpful to have a few more examples of successes and failures so that we might find a pattern. ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2005-03-26 13:34 Message: Logged In: YES user_id=1160854 The SIGSEGV problem still exists in current version (2.4.8 #984). I've done a full and fresh checkout... The attached file is a textfile with a screencopy ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2005-03-26 11:36 Message: Logged In: YES user_id=1160854 Sorry! The verion I used was 2.4.8 #983 *not* #980, as I wrote... ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2005-03-26 11:34 Message: Logged In: YES user_id=1160854 Yesterday (03/25/2005) I tried to find the reason of the "signal 11: SIGSEGV", but it's very difficult to find anything. Starting SDCC by the debugger GDB result in success (I tried *not* only once... So I put some "control point output" via printf into the source and detected in the first step that the SIGSEGV was raised within "emitRegularMaps". Than I took a closer look to the problem and found "iCode2eBBlock" called from "iCodeBreakDown" raising the signal. That's strang because the sourcecode of this function was not changed since 2.4.8 #977, which workes fine. Everything is done using Cygwin environment and with the lastest source (2.4.8 #980). I belief the problem must be some stages earlier. If can can do any support (tests, control outputs etc.) to solve the problem, please let me know. ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2005-03-24 23:28 Message: Logged In: YES user_id=1160854 Sorry! The version 977 is o.k. I'm using it for now, it's the snapshot of 03/19/05. The correct version causing the SIGSEGV is: $ ./sdcc -v SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds40 0/hc08 2.4.8 #983 (Mar 24 2005) (MINGW32) ---------------------------------------------------------------------- Comment By: Hubert Sack (hsack) Date: 2005-03-24 23:21 Message: Logged In: YES user_id=1160854 $ ./sdcc -v SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds40 0/hc08 2.4.8 #977 (Mar 24 2005) (MINGW32) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1170212&group_id=599 |