Download Reference Manual
The Developer's Library for D
About Wiki Forums Source Search Contact

Ticket #1094 (closed defect: wontfix)

Opened 7 years ago

Last modified 5 years ago

stack trace messed up un out of bounds error

Reported by: fawzi Assigned to: kris
Priority: major Milestone: External Bugs
Component: Core Functionality Version: trunk
Keywords: triage Cc:

Description

With GDC on intel macitosh 10.4 any program that generates an out of bound exception seems to somehow mess up the stacktrace (I think when trying to get the file name and line number of the place where the exception happens), or at least it does very ugly stuff with the stack. This happens even if I access a preallocated part (obtained setting the length higher and then smaller again).

In gdb I mange to get the stacktrace up to the callback for out of bounds errors

#0  _D6object12traceContextFPvZC9Exception9TraceInfo (ptr=0x0) at genobj.d:968
#1  0x00005de3 in _D6object9Exception5_ctorMFAaC9ExceptionZC9Exception (this=@0x509f00, msg={length = 25, ptr = 0x4a648 "Array index out of bounds"}, next=@0x0) at genobj.d:918
#2  0x00005e09 in _D6object9Exception5_ctorMFAaAakC9ExceptionZC9Exception (this=@0x509f00, msg={length = 25, ptr = 0x4a648 "Array index out of bounds"}, file={length = 13, ptr = 0x4993c "hello_tango.d"}, line=49, next=@0x0) at genobj.d:923
#3  0x000187b4 in onArrayBoundsError () at lifetime.d:99
Previous frame inner to this frame (corrupt stack?)

This is most likely a problem of GDC, even the callback _d_array_bounds is not shown.

Attachments

hello_tango.d (354 bytes) - added by fawzi on 05/08/08 10:34:24.
sample program showing the problem

Change History

05/08/08 08:30:43 changed by fawzi

Unfortunatly I was not able to reproduce the error with GDC/phobos, setting a breakpoint in the exception constructor (../../../gcc-4.1.2/libphobos/internal/object.d:1072) works, it seems to be tango related :(

I was able to bracket the problem a little more here:

(gdb) bt
#0  0x0002f6f8 in gc_malloc () at tango/text/convert/Layout.d:1
#1  0x000170a5 in _d_newclass (ci=@0x7b220) at lifetime.d:103
#2  0x000187b7 in onArrayBoundsError () at lifetime.d:99
#3  0x00001c04 in _Dmain (argv={length = 3221223336, ptr = 0x1786e}) at hello_tango.d:37
#4  0x0001786e in _D9dgccmain211_d_run_mainUiPPaPUAAaZiZi7runMainMFZv () at dgccmain2.d:287
#5  0x00017995 in _D9dgccmain211_d_run_mainUiPPaPUAAaZiZi7tryExecMFDFZvZv (dg={object = 0xbffff944, func = 0x1785c <_D9dgccmain211_d_run_mainUiPPaPUAAaZiZi7runMainMFZv>}) at dgccmain2.d:235
#6  0x00017e1b in _D9dgccmain211_d_run_mainUiPPaPUAAaZiZi6runAllMFZv () at dgccmain2.d:295
#7  0x00017995 in _D9dgccmain211_d_run_mainUiPPaPUAAaZiZi7tryExecMFDFZvZv (dg={object = 0xbffff944, func = 0x17dc4 <_D9dgccmain211_d_run_mainUiPPaPUAAaZiZi6runAllMFZv>}) at dgccmain2.d:235
#8  0x00017d21 in _d_run_main (argc=1, argv=0xbffffa00, main_func=0x1b68 <_Dmain>) at dgccmain2.d:302
#9  0x000054d2 in main (argc=-1073743400, argv=0x1a4e) at cmain.d:5
(gdb) step
0x00077156 in dyld_stub_memset ()
(gdb) step
Single stepping until exit from function dyld_stub_memset, 
which has no line number information.
0x90109c50 in memset ()
(gdb) step
Single stepping until exit from function memset, 
which has no line number information.
___bzero () at /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h:226
226     /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h: No such file or directory.
        in /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h
(gdb) bt
#0  ___bzero () at /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h:226
#1  0x00048220 in _D3gcx2GC12mallocNoSyncMFkkZPv () at tango/text/convert/Integer.d:1
#2  0x00048fe8 in _D3gcx2GC6mallocMFkkZPv () at tango/text/convert/Integer.d:1
Cannot access memory at address 0x1
Previous frame inner to this frame (corrupt stack?)

05/08/08 10:19:50 changed by fawzi

As it can be seen gc_malloc is already somehow broken (look at the file it is supposed to be in)

From what I can see the difference with phobos begin here phobos:

_d_newclass at ../../../gcc-4.1.2/libphobos/internal/gc/gc.d:171
             p = _gc.malloc(ci.init.length);

tango:

_d_newclass at lifetime.d:103
        p = gc_malloc(ci.init.length,
                      BlkAttr.FINALIZE | (ci.flags & 2 ? BlkAttr.NO_SCAN : 0));

but I do not see why then it gives problems...

This problem is present both in the latest trunk and 0.99.6

05/08/08 10:34:24 changed by fawzi

  • attachment hello_tango.d added.

sample program showing the problem

05/08/08 20:04:43 changed by sean

I think this may be a problem in the GDC compiler. It works fine on DMD/Win32.

05/09/08 18:33:46 changed by larsivi

It does also work with DMD on Linux, whereas GDC on 32 bit Linux produced a crash on line 192 of lib/compiler/gdc/lifetime.d

Tried to debug in Zero, but it didn't handle the typeinfo contents.

05/24/08 10:20:53 changed by larsivi

  • keywords set to triage.

07/10/08 10:58:48 changed by larsivi

  • milestone changed from 0.99.7 to 0.99.8.

07/26/08 17:04:55 changed by sean

  • status changed from new to assigned.
  • milestone changed from 0.99.8 to External Bugs.

If the crash occurs within lifetime.d then it's almost definitely a GDC bug of some sort. I say this because the code in lifetime.d is not substantially modified from how it is in gphobos, as your comparison of the "broken" code can attest. So I'm going to mark this as an external issue. If you're inclined to report it, please append the GDC bug tracker ID to this ticket.

11/09/09 01:14:17 changed by kris

  • status changed from assigned to new.
  • owner changed from sean to fawzi.

11/29/09 12:26:17 changed by fawzi

  • owner changed from fawzi to kris.

01/13/10 03:18:23 changed by kris

  • status changed from new to closed.
  • resolution set to wontfix.

Reopen if this is a problem with other compilers