Issue 51 in google-ctemplate: Segmentation fault in CreateSectionIterator and DumpSectionDict
codesite...@google.com
Owner: ----
New issue 51 by edv.tholmer: Segmentation fault in CreateSectionIterator
and DumpSectionDict
http://code.google.com/p/google-ctemplate/issues/detail?id=51
What steps will reproduce the problem?
Maybe its only for me reproducable. Here are my configurations
1. configure ctemplate 0.96/0.95 with ./configure --enable-static
--disable-shared (Host1, Host2 (see below))
What is the expected output? What do you see instead?
I expect a wondeful well formed xml file.
The template file has following structure: (sorry that I can not show the
original template file)
TemplateDictionary -> SectionDictionary -> SectionDictionary (Show/Hide
functionality)
-> SectionDictionary (Show/Hide
functionality)
-> SectionDictionary (Show/Hide
functionality)
-> SectionDictionary ->
SectionDictionary (Show/Hide functionality)
-> SectionDictionary (Show/Hide functionality) ->
SectionDictionary
In the section dicts always 1 or more vars.
What version of the product are you using? On what operating system?
ctemplate 0.95/0.96
Host 1: Linux version 2.6.27.38-170.2.113.fc10.i686 (gcc version 4.3.2
20081105 (Red Hat 4.3.2-7) (GCC) )
Host 2: Linux version 2.6.18-128.4.1.el5.centos.plus (gcc version 4.1.2
20080704 (Red Hat 4.1.2-44))
Please provide any additional information below.
The problem: When I start my program which was compiled on host 2, I get a
segmentation fault during expanding and/or dumping. On host 1, there is
absolutly no error without changing the code.
I debugged a little bit and here is a backtrace, maybe useful:
Program received signal SIGSEGV, Segmentation fault.
ctemplate::TemplateDictionary::DictionaryPrinter::DumpSectionDict
(this=0xbfd0f7ac, section_dict=@0x8e3720c)
at
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_iterator.h:650
650 in
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_iterator.h
(gdb) backtrace
#0 ctemplate::TemplateDictionary::DictionaryPrinter::DumpSectionDict
(this=0xbfd0f7ac, section_dict=@0x8e3720c)
at
/usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_iterator.h:650
#1 0x0812ee2c in
ctemplate::TemplateDictionary::DictionaryPrinter::DumpDictionary
(this=0xbfd0f7ac, dict=@0x8e37138) at src/template_dictionary.cc:786
#2 0x08130f86 in
ctemplate::TemplateDictionary::DictionaryPrinter::DumpSectionDict
(this=0xbfd0f7ac, section_dict=@0x8e370d0) at src/template_dictionary.cc:731
#3 0x0812ee2c in
ctemplate::TemplateDictionary::DictionaryPrinter::DumpDictionary
(this=0xbfd0f7ac, dict=@0x8ded288) at src/template_dictionary.cc:786
#4 0x081294d1 in ctemplate::TemplateDictionary::DumpToString
(this=0x8ded288, out=0xbfd0f9a8, indent=2) at src/template_dictionary.cc:731
row 826 in template_dictionary.cc: "for (DictVector::const_iterator it2 =
it->second->begin();"
I get the same error if using ctemplate 0.95
Generally:
I have six different template files which are similar to the example above.
Two of these template produce the segmentation fault but there are no
important differences
between them and the other templates. If I remove the first section
dictionary from the example above, the program runs greate, its very
strange.
My template vars only consits of letters and "_". I tested the templates
without modifier too, the same error.
I have to compile the program on host 2 and there is no possibility to
update the gcc.
I hope these information are enought.
Regards, Tholmer
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
codesite...@google.com
Labels: Type-Defect Priority-Medium
Comment #1 on issue 51 by csilvers: Segmentation fault in
CreateSectionIterator and DumpSectionDict
http://code.google.com/p/google-ctemplate/issues/detail?id=51
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?
codesite...@google.com
Comment #2 on issue 51 by edv.tholmer: Segmentation fault in
http://code.google.com/p/google-ctemplate/issues/detail?id=51
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".
codesite...@google.com
Comment #3 on issue 51 by edv.tholmer: Segmentation fault in
http://code.google.com/p/google-ctemplate/issues/detail?id=51
I could reproduce it with a minimal version of my original application.
Debug output, template and source code are in the attached file.
Attachments:
ctemplate_issue_51.txt 7.0 KB
codesite...@google.com
Comment #4 on issue 51 by csilvers: Segmentation fault in
http://code.google.com/p/google-ctemplate/issues/detail?id=51
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.
codesite...@google.com
Comment #5 on issue 51 by edv.tholmer: Segmentation fault in
http://code.google.com/p/google-ctemplate/issues/detail?id=51
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)
Attachments:
simplectemplate 2.0 MB
corefile 348 KB
main.cpp 2.0 KB
test.tpl 595 bytes
codesite...@google.com
Comment #6 on issue 51 by csilvers: Segmentation fault in
http://code.google.com/p/google-ctemplate/issues/detail?id=51
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.
codesite...@google.com
Comment #7 on issue 51 by edv.tholmer: Segmentation fault in
http://code.google.com/p/google-ctemplate/issues/detail?id=51
Ok, I think its acceptable to compile with -O1 to get a solution :)
Thank you for your fast responses! :)
codesite...@google.com
Status: Invalid
Comment #8 on issue 51 by csilvers: Segmentation fault in
CreateSectionIterator and DumpSectionDict
http://code.google.com/p/google-ctemplate/issues/detail?id=51
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.