segfaults

[Ellery Newcomer]

On 02/23/2010 10:34 AM, Robert Clipsham wrote:
>
> I'm no expert, but that looks like a dmd bug, can you reproduce with
> ldc? The actual segfault is probably to do with your code, but if gdb
> gives that then there's a problem with the debug info that dmd is
> writing. The only easy way to debug this if dmd's giving bad debug info
> is to use another compiler (I've never had issues using ldc and gdb with
> the patches from

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

> 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..

> 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!