Thank you for the fix!

Guerra

On 1/18/07, Borut Razem <borut.razem@siol.net> wrote:
Fixed in svn revision #4576.

Rodrigo, thank you for the report.

Borut


Rodrigo Guerra wrote:
> Okay, I will put some more data from gdb:
>
> (gdb) where
> #0  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
> #1  0x0000000000403690 in dbuf_vprintf (dbuf=0x799868, format=0x5f78e8
> ";Allocation info for local variables in function '%s'\n",
> args=0x7fff5da66bb0) at ../support/Util/dbuf_string.c:143
> #2  0x000000000040386e in dbuf_printf (dbuf=0x799868, format=0x5f78e8
> ";Allocation info for local variables in function '%s'\n") at
> ../support/Util/dbuf_string.c:176
> #3  0x0000000000442810 in printAllocInfo (func=0x87d280,
> oBuf=0x799868) at SDCCmem.c:1140
> #4  0x0000000000524516 in gen390Code (lic=0x895530) at gen.c:14206
> #5  0x00000000004fc3b2 in ds390_assignRegisters (ebbi=0x89f180) at
> ralloc.c:3410
> #6  0x0000000000424725 in eBBlockFromiCode (ic=0x895530) at SDCCopt.c:1585
> #7  0x000000000043c827 in createFunction (name=0x87d280,
> body=0x8940f0) at SDCCast.c:5995
> #8  0x00000000004046dc in yyparse () at SDCC.y:187
> #9  0x000000000041051e in main (argc=10, argv=0x7fff5da710a8,
> envp=0x7fff5da71100) at SDCCmain.c:2433
>
> (gdb) info locals
> p = 0x5f791b "s'\n"
> total_width = 85
> ap = {{gp_offset = 1571187632, fp_offset = 32767, overflow_arg_area =
> 0x5f78f0, reg_save_area = 0x7fff5da66bb0}}
>
> On 1/17/07, *wittb@ecs.csus.edu <mailto:wittb@ecs.csus.edu> *
> < wittb@ecs.csus.edu <mailto:wittb@ecs.csus.edu>> wrote:
>
>     Rodrigo  --
>
>     Cool!
>
>     In GDB, please use the command "info locals" .  That will display all
>     the local variables within the function that died.
>
>     Also a "where" command to print the stack backtrace.
>
>     This is really helpful!  Please post again.
>
>
>     kindest regards,
>     *the other brian
>
>     > Hi,
>     >
>     > 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
>     > (gdb)
>     >
>     > I will try to find out more later.
>     >
>     > Cheers,
>     > Guerra
>     >
>     > On 1/16/07, Frieder Ferlemann < frieder.ferlemann@web.de
>     <mailto: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.
>     >>
>     >>
>     >> Greetings,
>     >>
>     >> Frieder
>     >>
>


-------------------------------------------------------------------------
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
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user



--
Rodrigo da Silva Guerra
PhD Student

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