Peter Novak wrote:
> What I forgot to mention in my previous e-mail and what turned out to be
> crucial, is that my DLL uses std::cout for writing output to the
> console. I found, that whenever I have a print to cout in a routine, the
> subprocess crashes even *before* entering the routine(!). Struggling
> with gdb and multi-threaded application showed that the crash occurred
> in an esoteric place of:
The reason it crashes before your routine is called is that (assuming
PR26123 is in fact the cause) the problem has to do with the order of
static constructors. This happens at program startup (for objects in
the .exe) or at DLL load time (for objects in the .dll).
> The code there lists a remark about supposedly an issue of GLIBC (???):
> 59 template<typename _CharT, typename _Traits>
> 60 basic_ostream<_CharT, _Traits>&
> 61 basic_ostream<_CharT, _Traits>::
> 62 operator<<(__ostream_type& (*__pf)(__ostream_type&))
> 63 {
> 64 // _GLIBCXX_RESOLVE_LIB_DEFECTS
> 65 // DR 60. What is a formatted input function?
> 66 // The inserters for manipulators are *not* formatted output
> functions.
> 67 return __pf(*this);
> 68 }
The symbol/namespace _GLIBCXX in this context refers to gcc's libstdc++,
not glibc, so that's kind of a red herring. I don't think the above
comment has anything to do with your problem per se, as DR 60 is about
formatted input:
<http://gcc.gnu.org/onlinedocs/libstdc++/ext/lwg-defects.html#60>.
> Can somebody explain me why this worked the way it did? My guess is that
> it has something to do with Linux loading a shared library into the
> memory space of the running process, while on Win32 the DLL has it's own
> memory space (?)...
On both Win32 and Linux, shared libraries are in the same memory address
space as the executable; there's no difference in that respect.
> Anyway, it does not explain why loading DLL from the
> main thread was OK, while loading it from a subprocess wasn't (all
> components, i.e. main process, subprocess and DLL use cout to print
> stuff to console).
Well again, if the bug is in fact related to the order that static
constructors are run, then the difference in behavior could simply be
due to the fact that under the hood PE and ELF use different methods of
dispatching static ctors, so it follows that the order (which is
unspecified) could be volatile. By explicitly adding a
std::ios_base::Init static object I suppose you are somehow affecting
this order to cause it to be correct. I can't say for sure why this is,
but it's in general a very tricky aspect of C++, see also:
<http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12>.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
