[Bug 154] New: invalid code generation on linux with custom allocators/deallocators + 'auto' doubts

d-bugmail at puremagic.com d-bugmail at puremagic.com
Tue May 23 14:47:29 PDT 2006


http://d.puremagic.com/bugzilla/show_bug.cgi?id=154

           Summary: invalid code generation on linux with custom
                    allocators/deallocators + 'auto' doubts
           Product: D
           Version: 0.157
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: wrong-code
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla at digitalmars.com
        ReportedBy: h3r3tic at mat.uni.torun.pl


The following code:


tmp3.d:
----

import std.c.stdlib;

class Foo
{
    new (size_t sz)
    {
        return std.c.stdlib.malloc(sz);
    }

    delete(void* p)
    {
        if (p) std.c.stdlib.free(p);
    }
}

void main() {
    Foo f = new Foo;
    delete f;
}

----

doesn't seem to like linux at all...


h3 at h3:~/coding> dmd tmp3.d
gcc tmp3.o -o tmp3 -lphobos -lpthread -lm
h3 at h3:~/coding> ./tmp3
Illegal instruction
h3 at h3:~/coding> gdb tmp3
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-suse-linux"...Using host libthread_db library
"/lib/tls/libthread_db.so.1".

(gdb) r
Starting program: /home/h3/coding/tmp3
[Thread debugging using libthread_db enabled]
[New Thread 1075353280 (LWP 22608)]

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 1075353280 (LWP 22608)]
0x0805c474 in _Class_8TypeInfo ()
(gdb) bt
#0  0x0805c474 in _Class_8TypeInfo ()
#1  0x0804fc59 in _d_callfinalizer ()
#2  0x0804fa16 in _d_delclass ()
#3  0x0804a127 in _Dmain ()
#4  0x0804af03 in main ()


Adding an empty constructor ("this() {}") to the Foo class fixes the problem.
It's also been reported that it runs fine on Windows.


----

By the way, using custom deallocators in conjunction with 'auto' classes seems
to be problematic. The spec states "When an auto class reference goes out of
scope, the destructor (if any) for it is automatically called. This holds true
even if the scope was exited via a thrown exception.", yet it doesn't mention
custom deallocators.
When a class declares custom allocators and deallocators and an 'auto' instance
of such class is created, its custom allocator is called, but the custom
deallocator isn't. Is that the desired behaviour ? I hope not...

Thanks,
Tom


-- 




More information about the Digitalmars-d-bugs mailing list