I used DDD and found the segmentation fault to occur in line 121 of the file dbuf_string.c which looks like this:
120  case 's':
121    total_width += strlen (va_arg (ap, char *));
122    break;

In DDD the message shown at the botton is like this:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000403617 in calc_result_length (format=0x5f78e8 ";Allocation info for local variables in function '%s'\n", args=0x7fff5da66bb0) at ../support/Util/dbuf_string.c:121

I will try to find out more later.


On 1/16/07, Frieder Ferlemann < frieder.ferlemann@web.de> wrote:
Hello Rodrigo,

Rodrigo Guerra schrieb:
> I am using an up-to-date Ubuntu Edgy (kernel 2.6.17-10) in an AMD64.

Probably not many SDCC developers have already switched
to 64 bit systems... So they might not be able to reproduce.

> The last error message I get looks like this:
> make[2]: Entering directory `/home/guerra/sdcc-svn/device/lib'
> mkdir -p build/ds390
> ../../bin/sdcc -I../../device/include -I../../device/include/mcs51 -mds390
> --nostdinc --std-sdcc99 -c _autobaud.c -o build/ds390/_autobaud.rel
> Caught signal 11: SIGSEGV
> make[2]: *** [build/ds390/_autobaud.rel] Error 1

Something you could try to do to narrow things down is to
produce a core dump, which could then be examined by
a post-mortem debugger.

On that path would be:

- to enable core dumps on your system
  (typically edit/outcomment a line in /etc/profile like
   ulimit -c 30000 # only core-files less than 30 MB are written
  and then newly log into your system)

- reproduce the SIGSEGV error

- search for the core dump. Depending on your systems settings
  they may end up in home directory, the current directory or
  the /tmp directory. (The core dump might be called "core",
  "core.<process_ID>" or  "core.<date>".
  Note also that your Unix system might be configured to
  f.e. automatically delete core dumps after a week.)

- install a debugger like ddd

- open the core dump with ddd.
  You should be able to see the source-line where the error
  occurred and be able to examine the value of variables.
  Then use "show call stack" or "dump stack trace"
  or however it might be named to see from where the function
  was called.
  This information should/could be sufficient to fix the bug.



Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
Sdcc-user mailing list

Rodrigo da Silva Guerra
PhD Student

Department of Adaptive Machine Systems
Graduate School of Engineering
Osaka University - Japan