segfaults

[Robert Clipsham]

On 23/02/10 17:33, Ellery Newcomer wrote:
> Oh. good idea.
>
> mua ha ha. ldc dies on compile:
>
> ldc:
> /home/kamm/eigenes/projekte/ldc/llvm-26/lib/VMCore/Instructions.cpp:921:
> void llvm::StoreInst::AssertOK(): Assertion `getOperand(0)->getType() ==
> cast<PointerType>(getOperand(1)->getType())->getElementType() && "Ptr
> must be a pointer to Val type!"' failed.
> 0 ldc 0x0000000000df97bf
> 1 ldc 0x0000000000dfb46d
> 2 libpthread.so.0 0x000000302540f0f0
> 3 libc.so.6 0x00000030248326c5 gsignal + 53
> 4 libc.so.6 0x0000003024833ea5 abort + 373
> 5 libc.so.6 0x000000302482b7b5 __assert_fail + 245
> 6 ldc 0x0000000000d62c01 llvm::StoreInst::AssertOK() + 145
> 7 ldc 0x0000000000673206 DtoStore(llvm::Value*, llvm::Value*) + 102
> 8 ldc 0x000000000064814c DtoNewClass(Loc, TypeClass*, NewExp*) + 444
> 9 ldc 0x000000000065f930 NewExp::toElem(IRState*) + 832
> 10 ldc 0x000000000065f4f1 AssignExp::toElem(IRState*) + 193
> 11 ldc 0x0000000000617e14 DtoDeclarationExp(Dsymbol*) + 596
> 12 ldc 0x000000000065bf81 DeclarationExp::toElem(IRState*) + 65
> 13 ldc 0x000000000063fcdc ExpStatement::toIR(IRState*) + 108
> 14 ldc 0x000000000063fe67 CompoundStatement::toIR(IRState*) + 103
> 15 ldc 0x000000000063fdc8 ScopeStatement::toIR(IRState*) + 72
> 16 ldc 0x0000000000642f67 ForStatement::toIR(IRState*) + 951
> 17 ldc 0x000000000063fe67 CompoundStatement::toIR(IRState*) + 103

I don't know how you're compiling, but if you can figure out what file 
causes this you could file an ldc bug, working down a test case 
shouldn't be too hard from that :)

>> http://dsource.org/projects/gdb-patches/ ). I'd suggest reporting a dmd
>> bug too, but unless you can work this down to a test case then it'll
>> probably just be ignored... If your code is open source then someone
>> else could work it down, otherwise I can't see much use in reporting a
>> bug that can't be reproduced.
>>
>
> yeah, it's open source, but I don't think it's morally right to inflict
> it on others..

I see your point, but you may as well report a bug if it's open source, 
eventually someone will take a look at it... it's better to report it 
with a 200k LoC test than let the bug go unnoticed :) Of course if you 
can work it down then it'll be even easier, but I suspect that's a lot 
of effort.

>> Other options to try are compiling with -g, compiling with -gc and
>> seeing if you manage to get a better result, printf() debugging, using
>> another compiler, or compiling without debug info and getting a
>> backtrace... providing the binary isn't stripped you should still be
>> able to get function names, even if you can't get files/line numbers.
>
> ah. compile sans debug info works a bit better. thanks!

No problem, has it helped to narrow it down to the function/line of code 
it's happening in? If it has you might be able to narrow down a dmd bug ^