Just to close the thread, we managed to track down the bug in our
software, which caused stack or heap corruption and, in certain cases,
the crash. As for my actual questions, many thanks to Uli and Paul for
giving insight!
(For those interested in the nature of the bug: We use a custom struct
for time components, to be type casted to struct tm (see man localtime)
in the platform specific code, if supported. tm can contain two
extensions (not mentioned in the man pages, afaik), depending on how the
C library was configured. Our struct does not have the extensions, while
the C lib for this platform does. Thus, when calling localtime et al
with a pointer to our struct, but type casted to the extended struct tm,
it would write beyond our struct's boundary, corrupting the heap or
stack more or less fatally.)
Martin
>
> Hi everybody,
>
> First post, so thanks a lot for reading, and, hopefully, replying!
>
> When turning on optimisation (gcc 3.4.2, O2/Os -fno-strict-aliasing)
> when compiling our multi-platform software (C/C++ mix, target now is an
> embedded MIPS based platform) it segfaults, while it runs without a
> problem when turning optimisations off. I still get quite a few compiler
> warnings, so it is probably best to completely resolve them first.
>
> Still, there is something that strikes me as odd, and I would like to
> kindly ask if someone could shed some light on this. The crash occurs in
> the initialisation routine of a certain module. Now, when inserting a
> printf("bla") right at start-up in main() the crash goes away, removing
> it makes it re-appear, so it is perfectly reproducible. The printf is in
> a different object file than where the crash happens and quite a lot of
> code is executed between the printf and the crash.
>
> So my questions are:
> - Is this a side-effect to be expected?
> - How can the additional printf in one object file can have a
> side-effect on the code in another object file? (Each source file is
> compiled and optimised separately, so I guess it must happen during
> linkage, but that's where my understanding hits the wall.)
>
> Thanks again!
>
> Martin
>
>
_______________________________________________
help-gplusplus mailing list
help-gplusplus@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gplusplus
