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

Ticket #1082 (assigned defect)

Opened 4 months ago

Last modified 1 month ago

rt_attachDisposeEvent broken on x86-64?

Reported by: fawzi Assigned to: sean (accepted)
Priority: major Milestone: 0.99.8
Component: Core Functionality Version: 0.99.6 Jeff
Keywords: triage Cc:

Description

I haven't found any test using rt_attachDisposeEvent in tango, but doing tangobos signals.d unit test I get the following failures

==20871== Invalid write of size 8
==20871==    at 0x4EDE15: rt_attachDisposeEvent (genobj.d:1298)
==20871==    by 0x4953E6: _D3std7signals11__unittest0FZv3Foo16__T6SignalTAaTiZ7connectMFDFAaiZvZv (signals.d:196)
==20871==    by 0x494978: _D3std7signals11__unittest0FZv (signals.d:306)
==20871==    by 0x4FA381: _D5tango4core7Runtime18runModuleUnitTestsUZb14__foreachbody1MFKC10ModuleInfoZi (Runtime.d:166)
==20871==    by 0x4EDA5B: _D6object10ModuleInfo7opApplyFDFKC10ModuleInfoZiZi (genobj.d:1011)
==20871==    by 0x4FA3C5: runModuleUnitTests (Runtime.d:165)
==20871==    by 0x4F2F66: _D9dgccmain211_d_run_mainUiPPaPUAAaZiZi6runAllMFZv (dgccmain2.d:294)
==20871==    by 0x4F2A1D: _D9dgccmain211_d_run_mainUiPPaPUAAaZiZi7tryExecMFDFZvZv (dgccmain2.d:235)
==20871==    by 0x4F2E99: _d_run_main (dgccmain2.d:302)
==20871==    by 0x50CDAA9: (below main) (in /lib64/tls/libc.so.6)
==20871==  Address 0x52e3770 is 15 bytes after a block of size 1 alloc'd
==20871==    at 0x4A1BB69: malloc (vg_replace_malloc.c:207)
==20871==    by 0x4A1BCBA: realloc (vg_replace_malloc.c:429)
==20871==    by 0x4EDDC6: rt_attachDisposeEvent (genobj.d:1294)
==20871==    by 0x4953E6: _D3std7signals11__unittest0FZv3Foo16__T6SignalTAaTiZ7connectMFDFAaiZvZv (signals.d:196)
==20871==    by 0x494978: _D3std7signals11__unittest0FZv (signals.d:306)
==20871==    by 0x4FA381: _D5tango4core7Runtime18runModuleUnitTestsUZb14__foreachbody1MFKC10ModuleInfoZi (Runtime.d:166)
==20871==    by 0x4EDA5B: _D6object10ModuleInfo7opApplyFDFKC10ModuleInfoZiZi (genobj.d:1011)
==20871==    by 0x4FA3C5: runModuleUnitTests (Runtime.d:165)
==20871==    by 0x4F2F66: _D9dgccmain211_d_run_mainUiPPaPUAAaZiZi6runAllMFZv (dgccmain2.d:294)
==20871==    by 0x4F2A1D: _D9dgccmain211_d_run_mainUiPPaPUAAaZiZi7tryExecMFDFZvZv (dgccmain2.d:235)
==20871==    by 0x4F2E99: _d_run_main (dgccmain2.d:302)
==20871==    by 0x50CDAA9: (below main) (in /lib64/tls/libc.so.6)
==20871== 

It might be a tangobos error, but I haven't seen anything obviously wrong and on x86 it works.

Fawzi

Change History

05/24/08 06:19:39 changed by larsivi

  • keywords set to triage.

06/17/08 05:15:16 changed by larsivi

Could you make a minimal example not using tangobos?

06/18/08 01:41:00 changed by sean

Here's the code in rt_attachDisposeEvent that's apparently generating the error:

        auto len = m.devt.length + 4;
        auto pos = m.devt.length;
        auto p = realloc(m.devt.ptr, DEvent.sizeof * len);
        if (!p)
            onOutOfMemoryError();
        m.devt = (cast(DEvent*)p)[0 .. len];
        m.devt[pos+1 .. len] = null; // line 1298

So pos+1 is guaranteed to be less than len, and I can't find any indication that m.devt[pos+1 .. len] could be an invalid memory range. This leads me to think that this may be a GDC codegen bug of some sort. I don't suppose you can debug this and see what's going on?

07/10/08 07:01:12 changed by larsivi

  • milestone changed from 0.99.7 to 0.99.8.

Needs more thourough debugging or code gen checking.

07/26/08 13:06:18 changed by sean

  • status changed from new to assigned.

I don't suppose someone with 64-bit GDC can do this?