append to immutable array segfaults - anyone else seen it?

Adam D. Ruppe destructionator at gmail.com
Tue May 24 15:02:19 PDT 2011


One of my apps, seemingly at random, started crashing today. The
part at fault looked mostly like this:

===
   immutable(string[])[] records;

   foreach(immutableData; inputSource)
       records ~= [immutableData[1], immutableData[0]];
===

Nothing really fancy there except most everything was immutable. It
worked fine for a while. All my attempts to reduce it to a small
test case fail; the code works there too.

But, for some reason, the live code failed.


Looking into a debugger told me the segfault happened on lifetime.d
line 1967 in druntime:

/**
 * The old way, obsolete.
 */
extern (C) void* _d_arrayliteralT(TypeInfo ti, size_t length, ...)
{
    auto sizeelem = ti.next.tsize();            // array element size
    void* result;


It crashes on the array element size line. Neither ti nor ti.next
were null - both appeared to be valid references.


I changed from an array literal to a temporary object, and got
the same segfault, although in a different function. This, time,
it was here:

/**
 * Append y[] to array x[]
 */
extern (C) void[] _d_arrayappendT(TypeInfo ti, ref byte[] x, byte[] y)
{
    auto length = x.length;
    auto sizeelem = ti.next.tsize();            // array element size




Since the problem was consistently related to typeinfo, I did a hack
fix:

===
   string[][] records;

   foreach(immutableData; inputSource)
       records ~= cast(string[]) [immutableData[1], immutableData[0]];
===

That is: I casted away immutable, and everything works now.




The reason I'm in the newsgroup rather than the bugzilla is I really
have no idea what's going on here. Since I can't recreate it
in a minimal test, that makes it all the harder.


Of all the D2 features, I've had the most trouble, by far, with
immutable array typeinfos randomly disappearing...


Has anyone else seen this? While my cast papers over the immediate
problem, I'd really like to get to the bottom of it and fix it
permanently.

If no one else has seen it, it might be a bug in my code, memory
corruption or something, but it seems awfully unlikely that memory
corruption would always hit a typeinfo structure like I've seen.


More information about the Digitalmars-d mailing list