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] <[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]> 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
>>
--
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