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

Reply via email to