Thank you for the fix!
Guerra
On 1/18/07, Borut Razem <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> *
> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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 <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> 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
-------------------------------------------------------------------------
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
