Segmentation fault in CreateSectionIterator and DumpSectionDict

[olafvdspek]

Segmentation fault in CreateSectionIterator and DumpSectionDict

[GoogleCodeExporter]

Tricky.  Unfortunately, this isn't enough information to determine what's going 
on.  
It looks like a data structure is getting corrupted.  It could have to do with 
the 
different compilers/machines you're using, or maybe not.

It will be hard to debug this.  If you can give an example program -- 
preferably a 
simple one -- which demonstrates the problem, it might help, though no 
guarantees.

Is your application multi-threaded?  Do you ever add to a single dictionary 
from 
multiple threads?

Original comment by [email protected] on 19 Jan 2010 at 3:28

• Added labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

I will try to reproduce this problem with a simpler program and upload it here.

My application is multi threaded yes. On thread fill the dictionaries and push 
them
on a queue for the second thread. Just this minute I tested it without threads, 
only
one thread which fill the dictionary and expand it, same error.

Are there some special keywords reserved for the template vars? Except 
__{{MAIN}}__
All my sections I use for "SetValueAndShowSection" starts with "IF", eg. 
"IFHOMEPAGE"
or "IFFOO" or "IFBAR".

Original comment by [email protected] on 19 Jan 2010 at 12:13

[GoogleCodeExporter]

I could reproduce it with a minimal version of my original application.

Debug output, template and source code are in the attached file.

Original comment by [email protected] on 19 Jan 2010 at 3:08

Attachments:

• ctemplate_issue_51.txt

[GoogleCodeExporter]

I took a look at the example file, and it all seems straightforward to me.  I 
wonder 
if it's a compiler bug somewhere or something.

Try building ctemplate without optimization:
   ./configure CXXFLAGS=-g

At the very least, it may give a more-useful backtrace when it fails.  See if 
that 
turns up anything obvious.  If not, it may be helpful to attach both the actual 
running executable and the core file to this bug report.  I can poke around in 
gdb 
and see if I see anything obvious (though it may not work, depending on how 
similar 
our systems are).

Another thing you could try is ripping bits out of the application to get an 
even 
smaller example that tickles the bug (for instance -- does it still crash if 
you get 
rid of the outer for loop?)  That may also give hints as to what is going on.

Original comment by [email protected] on 19 Jan 2010 at 8:32

[GoogleCodeExporter]

Surprise, surprise...

I compiled ctemplate-0.96 with gcc 4.1.2 and the following flags: CXXFLAGS="-O0 
-g3"
Now my application dont crash, both the example and the original. I continue 
testing
with:
CXXFLAGS="-O0" => Success
CXXFLAGS="-O1" => Success
CXXFLAGS="-O2" => Crash

Maybe there is a compiler bug during optimisation!?

Attached Files:
simplectemplate -> executable file
corefile -> core dump
main.cpp -> minimized code
test.tpl -> template (not changed since last post)

Original comment by [email protected] on 20 Jan 2010 at 10:50

Attachments:

• simplectemplate
• corefile
• main.cpp
• test.tpl

[GoogleCodeExporter]

An optimization bug is a likely candidate.  I'm not sure what to suggest except 
that 
you compile with -O1. :-)  If are able to find out more details about what 
triggers 
the (presumed) bug, and there's an easy way to work around it, that's fine, but 
I 
think there's not much point in working around bugs in not-current-release 
compilers.  
I'll give it a few days, but my guess is I'll be closing the bug WontFix.

Original comment by [email protected] on 20 Jan 2010 at 4:48

[GoogleCodeExporter]

Ok, I think its acceptable to compile with -O1 to get a solution :)
Thank you for your fast responses! :)

Original comment by [email protected] on 21 Jan 2010 at 2:23

[GoogleCodeExporter]

OK, I'll close this bug as "Invalid" then, under the assumption it's a compiler 
bug we 
can't do anything about.  But if you figure out what's going on, and there's an 
easy 
workaround, let me know and I'll reopen the bug.

Original comment by [email protected] on 2 Feb 2010 at 11:46

• Changed state: Invalid