#232 _STLP_DEBUG uses singleton

[Nigel Stewart]

I observed some problems with using _STLP_DEBUG on Linux (the app would deterministically freeze up) and it was root-caused as being due to more than one library using STLport without linking the STLport library. The debug-mode internals use a singleton, but the libraries were having one singleton-per-library. I suggest mentioning this in the context of:

http://www.stlport.com/doc/debug_mode.html
http://stlport.sourceforge.net/FAQ.shtml#library

Knowing this limitation of _STLP_DEBUG I'm happy to build those libraries in a different way to workaround the issue, for troubleshooting purposes.
I don't see an easy automated way of detecting this situation at compile-time or runtime, unfortunately.

[Petr Ovtchenkov]

Unclear: what the problem? "I observed some problem." is far from description of the problem.

[Nigel Stewart]

Problem: An application using libraries built with _STLP_DEBUG=1 would freeze. gdb reveals that STLport is trying to lock a mutex, eventhough the application is single-threaded.

[Petr Ovtchenkov]

Not like a bug description. It remains unclear. If you mean that you application don't link with thread library, then

ldd ../../src/obj/gcc/so_stlg/libstlportstlg.so.6.0
linux-gate.so.1 => (0xb803d000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb7f64000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7f4c000)
libc.so.6 => /lib/libc.so.6 (0xb7e01000)
/lib/ld-linux.so.2 (0xb803e000)
libm.so.6 => /lib/libm.so.6 (0xb7ddc000)

[Nigel Stewart]

A few comments:

- This issue was filed as a "documentation issue". I'm not not meaning to imply there is anything wrong with the implementation of _STLP_DEBUG or the use of threading or pthreads by STLport. The purpose of this report is to suggest possible improvement to the _documentation_ of _STLP_DEBUG.
- We have two libraries, let's call them A and B. Both use STLport _without_ linking to the STLport library. Libraries A and B both read and write to data structures containing std::string, std::vector, std::hash_map etc. The libraries A and B currently only support single-threaded calls, so it is undesirable for STLport to be making pthreads calls internally. (Wasted overhead)
- In this "no STLport library" arrangement it is obvious that there can be no singletons across both A and B in the way _STLP_DEBUG requires.
- The FAQ states "you can't use iostreams, locale, complex" but in fact _STLP_DEBUG can't be used either. A similar statement ought to appear in the debug-mode page too, in my opinion.

I hope that helps clarify the issue.

Regards,

Nigel Stewart