Discussion:
std::string problem!
(too old to reply)
Jøhnny Fävòrítê (it means "halo, then resonate")
2004-08-28 14:05:13 UTC
Permalink
could somebody help me verify something?

it appears that having any static std::string variables causes random
heap corruption. i've been vaguely suspicious of something like this
for a long time, because i've had unexplained occasional crashes in the
global destructors for months now. just today i've finally narrowed
down a test case that always crashes for me.

create a new BeIDE project that uses the BeSTL stationery. it only
needs one source file, like this:

#include <string>
std::string iAmStatic;

int main(int argc, const char** argv)
{
return 0;
}

from the edit menu, pick "Project Settings," then "x86 Code Generation."
click the check boxes for "Generate profiling code" and "Generate
Debugging Information." build the app, and run it from the command
line. on my box, it usually prints:

What the hell! User addr doesn't start at 0x80000000

and then it *always* crashes in the global destructors that get run
after main(). if i comment out the std::string declaration and rebuild,
everything works fine. i'm running plain old stock beos 5.0.3 on x86.

could somebody please try this test and report what happens? there's
nothing i'd love to hear more than it works for other people, which
might mean that my libstdc++.r4.so lib is corrupt or something.
Alexander G. M. Smith
2004-08-31 00:47:30 UTC
Permalink
Post by Jøhnny Fävòrítê (it means "halo, then resonate")
What the hell! User addr doesn't start at 0x80000000
I don't get the string printed, but I do get the crash when compiled with
those options (works OK with other options).

BeSTL:sc
frame retaddr
fd0006e8 ec08e900 _free + 0000002c
fd00070c ec08383f free + 0000005b
fd000728 ec24c145 BList::~BList(void) + 00000029
fd000740 ec1ab54e global destructors keyed to BDragger::sVisible +
0000001e
fd000754 ec15d4d3 __do_global_dtors_aux + 00000043
fd000764 ec25c298 ._fini + 00000017
fd000770 ec083eed call_routine_in_order + 0000016d
fd001bd8 ec0842a5 _call_term_routines_ + 00000019
fd001bec ec04a9ca exit + 0000009a
fd001c00 80001ec2 _start + 0000006e
BeSTL:
Jøhnny Fävòrítê (it means "halo, then resonate")
2004-08-31 04:57:43 UTC
Permalink
Post by Alexander G. M. Smith
I don't get the string printed, but I do get the crash when compiled
with those options (works OK with other options).
thanks for trying it out. your stack trace is nearly identical to the
one i got. now i know i'm not crazy.

so, at the very least, static variables with constructors and
destructors are incompatible with beos profiling. (i've done more tests
and it's not just std::string, any variable with a non-trivial
destructor causes the same result.) i've got a suspicion that the heap
is subtly corrupted as well, but i'll need more tests before i can say
for sure.
Alexander G. M. Smith
2004-09-01 12:02:22 UTC
Permalink
I wonder if that explains the occasional crash on exit of MDR. Did Nathan
add any static STL data structures for IMAP? I'll have to get a stack crawl
next time it crashes...

- Alex
Jøhnny Fävòrítê (it means "halo, then resonate")
2004-09-01 16:16:54 UTC
Permalink
Post by Alexander G. M. Smith
I wonder if that explains the occasional crash on exit of MDR. Did
Nathan add any static STL data structures for IMAP? I'll have to get
a stack crawl next time it crashes...
i've been experimenting some more, and i *think* it's just std::string
with the problem. i was able to create a simple static object with a
constructor and destructor, and enabled profiling, and the app didn't
crash. but i've been going around in circles on this for so long that
i'm not going to say anything definitive. i think i'll just leave it be
for awhile and come back to it later on.
voidref
2004-09-19 10:36:21 UTC
Permalink
Post by Jøhnny Fävòrítê (it means "halo, then resonate")
Post by Alexander G. M. Smith
I wonder if that explains the occasional crash on exit of MDR. Did
Nathan add any static STL data structures for IMAP? I'll have to get
a stack crawl next time it crashes...
i've been experimenting some more, and i *think* it's just std::string
with the problem. i was able to create a simple static object with a
constructor and destructor, and enabled profiling, and the app didn't
crash. but i've been going around in circles on this for so long that
i'm not going to say anything definitive. i think i'll just leave it be
for awhile and come back to it later on.
I remember Chris Tate fixing a bug in the std::string desctructor post
R5, but I think it was in regards to thread safety, or ref counting.

Look for it in Zeta. =)

alan

Continue reading on narkive:
Loading...