Haunting a Windows "Subsurface not start but becoming zombie" bug

2017-04-09 Thread Stefan Fuchs 
Hi All,

I'm trying to haunt another issue I'm seeing already since a long time
(months):

It is that simply sometimes Subsurface under Windows 10 doesn't start. I
mean I click on the icon and no window and also no crash info appears.
After that I have a zombie Subsurface.exe running. I now for the first
time reproduced this with the MXE debug build and again attached drmingw
to the zombie exe.

Can s.o. guess s.th. from the output?

What else could I provide to help finding this bug?


Best regards
Stefan

-- 

Stefan Fuchs
E-Mail: sfu...@gmx.de 

subsurface.exe caused a Breakpoint at location 7FFEAB819920 in module 
ntdll.dll.

Registers:
eax=0001 ebx=6fed6d00 ecx= edx= esi= edi=0190
eip=775ce5fc esp=4fdbdc44 ebp=4fdbdcb4 iopl=0 nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b efl=0206

AddrPC   Params
775CE5FC 0190    ntdll.dll!_NtWaitForSingleObject@12
74D0AE49 0190    KERNELBASE.dll!_WaitForSingleObjectEx@12
74D0ADA2 0190  4FDBDD00  KERNELBASE.dll!_WaitForSingleObject@8
6FE4A940 4FDBDDCC  743B8A93  
libstdc++-6.dll!__gthr_win32_recursive_mutex_lock  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-gcc-i686-w64-mingw32.shared/gcc-4.9.4/libgcc/config/i386/gthr-win32.c
 @ 215]
743B8A93 0003 0001 4FDBDE54  USER32.dll!_DispatchHookW@16
743B80DC 4FDBDE70 743B7FD0 4FDBFC9C  USER32.dll!CallHookWithSEH
743B802B 4FDBDE44 0030 4FDBFF68  USER32.dll!__fnHkINLPMSG
775D08C6 4FDBFC9C    ntdll.dll!_KiUserCallbackDispatcher@12
743B6AD7   0001  USER32.dll!_PeekMessage
743B6A6D 4FDBFC9C    USER32.dll!PeekMessageW
04075740 0002  74777410  Qt5Cored.dll!processEvents  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/kernel/qeventdispatcher_win.cpp
 @ 776]
04016C4E 0024 4FDBFDCC 4FDBFDF0  Qt5Cored.dll!processEvents  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/kernel/qeventloop.cpp
 @ 134]
04016F87  4FDBFF20 4FDBFEB8  Qt5Cored.dll!exec  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/kernel/qeventloop.cpp
 @ 210]
03E9CC5C     Qt5Cored.dll!exec  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/thread/qthread.cpp
 @ 507]
03E9CE57 0001 4F7A67F8 0009  Qt5Cored.dll!run  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/thread/qthread.cpp
 @ 574]
03EA0950 747773A6 4F6A0998 B62AC012  Qt5Cored.dll!start  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/thread/qthread_win.cpp
 @ 391]
747773A6 4FDBFF94 75BD62C4 4F696528  msvcrt.dll!_callthreadstartex
74777471 4F696528 75BD62A0 B79649A2  msvcrt.dll!_threadstartex
75BD62C4 4F696528 B536046E   KERNEL32.DLL!@BaseThreadInitThunk@12
775C0FD9  775E2F09   ntdll.dll!__RtlUserThreadStart
775C0FA4 74777410 4F696528   ntdll.dll!__RtlUserThreadStart@8

Registers:
eax=74777410 ebx= ecx= edx= esi=000a edi=000a
eip=775ceb8c esp=4b5c ebp=4cec iopl=0 nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b efl=0206

AddrPC   Params
775CEB8C 000A 4F6238D0 0001  ntdll.dll!_NtWaitForMultipleObjects@20
74D11BF0 000A 4F6238D0   KERNELBASE.dll!_WaitForMultipleObjectsEx@20
74D11AE8 000A 4F6238D0   KERNELBASE.dll!_WaitForMultipleObjects@16
03FC8D5D 0001 4F7E4628 0008  Qt5Cored.dll!run  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/io/qfilesystemwatcher_win.cpp
 @ 345]
03EA0950 747773A6 4F7E96C8 B60EC012  Qt5Cored.dll!start  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/thread/qthread_win.cpp
 @ 391]
747773A6 4F94 75BD62C4 4F696300  msvcrt.dll!_callthreadstartex
74777471 4F696300 75BD62A0 B7B249A2  msvcrt.dll!_threadstartex
75BD62C4 4F696300 B512046E   KERNEL32.DLL!@BaseThreadInitThunk@12
775C0FD9  775E2F09   ntdll.dll!__RtlUserThreadStart
775C0FA4 74777410 4F696300   ntdll.dll!__RtlUserThreadStart@8

Registers:
eax= ebx=03c7efc0 ecx= edx= esi= edi=02a8
eip=775ce5fc esp=03c7ebf8 ebp=03c7ec68 iopl=0 nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b efl=0202

AddrPC   Params
775CE5FC 02A8    ntdll.

Re: Haunting a Windows "Subsurface not start but becoming zombie" bug

2017-04-09 Thread Lubomir I. Ivanov 
hello,

On 9 April 2017 at 14:09, Stefan Fuchs  wrote:
> Hi All,
>
> I'm trying to haunt another issue I'm seeing already since a long time
> (months):
>
> It is that simply sometimes Subsurface under Windows 10 doesn't start. I
> mean I click on the icon and no window and also no crash info appears. After
> that I have a zombie Subsurface.exe running. I now for the first time
> reproduced this with the MXE debug build and again attached drmingw to the
> zombie exe.
>
> Can s.o. guess s.th. from the output?
>
> What else could I provide to help finding this bug?
>
>

so it appears to be entering an infinite loop when
desktop-widgets/globe.cpp calls setShowScaleBar(true);
it then tries to redirect debug output to a "NullStream" in
MarbleDebug.cpp which appears to fail on Windows.
QDebug attempts to acquire a Mutex lock but fails in
qmutex.cpp::setInternal() (wait()).

i will add a CC to Thiago Macieira to see if he has the time to check
your stack trace.

you could try:
1) in globe.cpp do a on top:
#include "MarbleDebug.h"

then above setShowScaleBar(true); call:
MarbleDebug::setEnabled(false);

2) if the above fails try:
open the Marble source folder and find MarbleDebug.cpp and modify the
contents of the method mDebug() to be like so:
QDebug mDebug()
{
return qDebug();
}
then rebuild marble.

3) you could also try a different Qt version.

solution 1) is tolerable to be enabled only on Windows on the side of
Subsurface, but ideally the fix should be on the Marble side.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Haunting a Windows "Subsurface not start but becoming zombie" bug

2017-04-09 Thread Stefan Fuchs 
Hi Lubomir,

thanks for looking into this!


Am 09.04.2017 um 14:37 schrieb Lubomir I. Ivanov:
>> It is that simply sometimes Subsurface under Windows 10 doesn't start. I
>> mean I click on the icon and no window and also no crash info appears. After
>> that I have a zombie Subsurface.exe running. I now for the first time
>> reproduced this with the MXE debug build and again attached drmingw to the
>> zombie exe.
> so it appears to be entering an infinite loop when
> desktop-widgets/globe.cpp calls setShowScaleBar(true);
> it then tries to redirect debug output to a "NullStream" in
> MarbleDebug.cpp which appears to fail on Windows.
> QDebug attempts to acquire a Mutex lock but fails in
> qmutex.cpp::setInternal() (wait()).
>
> i will add a CC to Thiago Macieira to see if he has the time to check
> your stack trace.
>
> you could try:
> 1) in globe.cpp do a on top:
> #include "MarbleDebug.h"
>
> then above setShowScaleBar(true); call:
> MarbleDebug::setEnabled(false);
This variant 1) does build.
Then when running it under Windows 10 it does show a similar behaviour:
It starts 95% of the times but again sometimes I end up with a zombie
process.
I again attached drmingw. Result is attached to this mail. From what I
can see still marble is involved.

> 2) if the above fails try:
> open the Marble source folder and find MarbleDebug.cpp and modify the
> contents of the method mDebug() to be like so:
> QDebug mDebug()
> {
> return qDebug();
> }
> then rebuild marble.
Depending on your feedback I can test this as well. Didn't do it yet.
> 3) you could also try a different Qt version.
No fun ;-)
I have bad experience with MXE and I'm happy that I found an MXE version
where the release and debug build and the resulting executable works.
This is for me MXE release 2016-10-12 which comes with Qt5.7.

Best regards
Stefan

-- 

Stefan Fuchs
E-Mail: sfu...@gmx.de 

subsurface.exe caused a Breakpoint at location 7FF8F53D9920 in module 
ntdll.dll.

Registers:
eax= ebx=0004 ecx= edx= esi= edi=0080
eip=771de5fc esp=03c7e728 ebp=03c7e798 iopl=0 nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b efl=0206

AddrPC   Params
771DE5FC 0080    ntdll.dll!_NtWaitForSingleObject@12
76E6AE49 0080    KERNELBASE.dll!_WaitForSingleObjectEx@12
03ED92B9  0001 03C7E808  Qt5Cored.dll!wait  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/thread/qmutex_win.cpp
 @ 65]
03ED8BAE  0001 03C7E86C  Qt5Cored.dll!lockInternal  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/thread/qmutex.cpp
 @ 508]
03ED8954 0001 5942D738 03C7E858  Qt5Cored.dll!lockInternal  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/thread/qmutex.cpp
 @ 424]
03ED8851 5931404C 03C7E8FC 03C7E8B8  Qt5Cored.dll!lock  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/thread/qmutex.cpp
 @ 230]
04118CB6 043C706C  03C7E8E8  Qt5Cored.dll! ??   
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/../../include/QtCore/../../src/corelib/tools/qarraydata.h
 @ 122]
04089102 59314048 0003 0001  Qt5Cored.dll!activate  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/kernel/qobject.cpp
 @ 3635]
04088E76 59314048 22A5868C 0001  Qt5Cored.dll!activate  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/kernel/qobject.cpp
 @ 3602]
22783CFA 03C7EA6C 22AA6BC7 03C7EA00  libssrfmarblewidgetd.dll!repaintNeeded  
[/home/stefan/Entwicklung/Subsurface/win32/marble/src/lib/marble/TextureLayer.moc
 @ 248]
2278302C 03C7EBDC  000B  libssrfmarblewidgetd.dll!setNeedsUpdate  
[/home/stefan/Entwicklung/Subsurface/marble-source/src/lib/marble/layers/TextureLayer.cpp
 @ 420]
227A4980 03C7EBDC  22AA6B59  libssrfmarblewidgetd.dll!setPropertyValue  
[/home/stefan/Entwicklung/Subsurface/marble-source/src/lib/marble/MarbleMap.cpp 
@ 1003]
227A207B 03C7EDAC 593A1F18 03C7EDB8  libssrfmarblewidgetd.dll!updateMapTheme  
[/home/stefan/Entwicklung/Subsurface/marble-source/src/lib/marble/MarbleMap.cpp 
@ 816]
227A6D7A 593A1F14  0037  
libssrfmarblewidgetd.dll!qt_static_metacall  
[/home/stefan/Entwicklung/Subsurface/win32/marble/src/lib/marble/MarbleMap.moc 
@ 375]
040896E3 593A1F08 0003 0001  Qt5Cored.dll!activate  
[/home/stefan/Entwicklung/Subsurface/mxe-2016-10-12/tmp-qtbase-i686-w64-mingw32.shared/qtbase-opensource-src-5.7.0/src/corelib/kernel/

Re: Haunting a Windows "Subsurface not start but becoming zombie" bug

2017-04-09 Thread Lubomir I. Ivanov 
On 9 April 2017 at 17:33, Stefan Fuchs  wrote:
> Hi Lubomir,
>
> thanks for looking into this!
>
>
> Am 09.04.2017 um 14:37 schrieb Lubomir I. Ivanov:
>
> It is that simply sometimes Subsurface under Windows 10 doesn't start. I
> mean I click on the icon and no window and also no crash info appears. After
> that I have a zombie Subsurface.exe running. I now for the first time
> reproduced this with the MXE debug build and again attached drmingw to the
> zombie exe.
>
> so it appears to be entering an infinite loop when
> desktop-widgets/globe.cpp calls setShowScaleBar(true);
> it then tries to redirect debug output to a "NullStream" in
> MarbleDebug.cpp which appears to fail on Windows.
> QDebug attempts to acquire a Mutex lock but fails in
> qmutex.cpp::setInternal() (wait()).
>
> i will add a CC to Thiago Macieira to see if he has the time to check
> your stack trace.
>
> you could try:
> 1) in globe.cpp do a on top:
> #include "MarbleDebug.h"
>
> then above setShowScaleBar(true); call:
> MarbleDebug::setEnabled(false);
>
> This variant 1) does build.
> Then when running it under Windows 10 it does show a similar behaviour: It
> starts 95% of the times but again sometimes I end up with a zombie process.
> I again attached drmingw. Result is attached to this mail. From what I can
> see still marble is involved.
>

in practice, things like the "runs 95% of time" are complicated to debug.

for now you can try commenting out this line in globe.cpp:
setMapThemeId("earth/googlesat/googlesat.dgml");

but this disables the Marble theme.

we do have reports by Windows 10 users about Marble issues:
https://github.com/Subsurface-divelog/subsurface/issues/169

which may hint about a generic Windows 10 / Marble problem, of sorts.
the thing is, your reports point towards Qt methods which is troubling.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Haunting a Windows "Subsurface not start but becoming zombie" bug

2017-04-09 Thread Stefan Fuchs 
Hello Lubomir,


Am 09.04.2017 um 14:37 schrieb Lubomir I. Ivanov:
>
>> It is that simply sometimes Subsurface under Windows 10 doesn't start. I
>> mean I click on the icon and no window and also no crash info appears. After
>> that I have a zombie Subsurface.exe running. I now for the first time
>> reproduced this with the MXE debug build and again attached drmingw to the
>> zombie exe.
> so it appears to be entering an infinite loop when
> desktop-widgets/globe.cpp calls setShowScaleBar(true);
> it then tries to redirect debug output to a "NullStream" in
> MarbleDebug.cpp which appears to fail on Windows.
> QDebug attempts to acquire a Mutex lock but fails in
> qmutex.cpp::setInternal() (wait()).
>
> [...]
>
> 2) if the above fails try:
> open the Marble source folder and find MarbleDebug.cpp and modify the
> contents of the method mDebug() to be like so:
> QDebug mDebug()
> {
> return qDebug();
> }
> then rebuild marble.
Now I have this variant 2) build and running.
No more occurrence of the zombie process phenomenon up to now and also
marble showing the globe plus dive site after every startup.
I will continue my testing and poor  development work based on this
change and watch out for further recurrence of this issue or any other.

Clearly I don't know what that may mean in terms of marble: That code
piece with the "NullStream" not good for windows?!

Best regards
Stefan

-- 

Stefan Fuchs
E-Mail: sfu...@gmx.de 

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Haunting a Windows "Subsurface not start but becoming zombie" bug

2017-04-09 Thread Lubomir I. Ivanov 
On 9 April 2017 at 22:04, Stefan Fuchs  wrote:
> Clearly I don't know what that may mean in terms of marble: That code piece
> with the "NullStream" not good for windows?!
>

their NullSream class idea is to redirect output to a "null" device if
debugging is disabled.
e.g. /dev/null on *NIX and NUL on Windows.

but it appears their approach doesn't work well with this version of
Qt and on Windows.

i would try something like that instead:

static QFile *nullDevice = new QFile(QProcess::nullDevice());
if (!nullDevice->isOpen())
nullDevice->open(QIODevice::WriteOnly);
return QDebug(nullDevice);

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Haunting a Windows "Subsurface not start but becoming zombie" bug

2017-04-09 Thread Thiago Macieira 
Em domingo, 9 de abril de 2017, às 04:09:43 PDT, Stefan Fuchs escreveu:
> Hi All,
> 
> I'm trying to haunt another issue I'm seeing already since a long time
> (months):
> 
> It is that simply sometimes Subsurface under Windows 10 doesn't start. I
> mean I click on the icon and no window and also no crash info appears.
> After that I have a zombie Subsurface.exe running. I now for the first
> time reproduced this with the MXE debug build and again attached drmingw
> to the zombie exe.
> 
> Can s.o. guess s.th. from the output?

Looks like it's a deadlock, caused by the GCC implementation on Windows 
violating a C++11 requirement.

You have three (or more) threads running. The interesting ones are:
 A) an aux thread that is calling PeekMessage, but somehow recurses through a 
hook to __gthr_win32_recursive_mutex_lock
 B) an aux thread that is trying to lock a mutex and is stuck in 
QMutexPrivate::allocate, having called __gthr_win32_recursive_mutex_lock
 C) the main thread, that is stuck in a mutex wait

Guessing at what in QMutexPrivate::allocate could cause a call to 
__gthr_win32_recursive_mutex_lock, I can only come up with the function-local 
static:

FreeList *freelist()
{
static FreeList list;
return &list;
}

The C++11 standard says that such initialisation must be thread-safe and must 
not deadlock. Hence why I think that this is a violation of the C++ standard.

In any case, the code above no longer exists. It was changed in Qt 5.7.1. 
Please upgrade.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Haunting a Windows "Subsurface not start but becoming zombie" bug

2017-04-09 Thread Lubomir I. Ivanov 
On 10 April 2017 at 01:12, Thiago Macieira  wrote:
> Em domingo, 9 de abril de 2017, às 04:09:43 PDT, Stefan Fuchs escreveu:
>> Hi All,
>>
>> I'm trying to haunt another issue I'm seeing already since a long time
>> (months):
>>
>> It is that simply sometimes Subsurface under Windows 10 doesn't start. I
>> mean I click on the icon and no window and also no crash info appears.
>> After that I have a zombie Subsurface.exe running. I now for the first
>> time reproduced this with the MXE debug build and again attached drmingw
>> to the zombie exe.
>>
>> Can s.o. guess s.th. from the output?
>
> Looks like it's a deadlock, caused by the GCC implementation on Windows
> violating a C++11 requirement.
>
> You have three (or more) threads running. The interesting ones are:
>  A) an aux thread that is calling PeekMessage, but somehow recurses through a
> hook to __gthr_win32_recursive_mutex_lock
>  B) an aux thread that is trying to lock a mutex and is stuck in
> QMutexPrivate::allocate, having called __gthr_win32_recursive_mutex_lock
>  C) the main thread, that is stuck in a mutex wait
>
> Guessing at what in QMutexPrivate::allocate could cause a call to
> __gthr_win32_recursive_mutex_lock, I can only come up with the function-local
> static:
>
> FreeList *freelist()
> {
> static FreeList list;
> return &list;
> }
>
> The C++11 standard says that such initialisation must be thread-safe and must
> not deadlock. Hence why I think that this is a violation of the C++ standard.
>
> In any case, the code above no longer exists. It was changed in Qt 5.7.1.
> Please upgrade.
>

i did a couple of tests to see if the singleton is even protected with
mingw 4.9.2:

gcc -v
gcc version 4.9.2 (i686-posix-dwarf-rev1, Built by MinGW-W64 project)

g++ test.cpp -Wall -std=c++11 -O1 -S -o test-meyer.S

so, it's guarded with ___cxa_guard_acquire() and it appears that the
c++11 flag doesn't matter much.
the "static Foo inst;" being outside of the function body is not guarded.

___cxa_guard_acquire() calls __gthr_win32_recursive_mutex_lock() which
has WaitForSingleObject().
so if the static initialization causes the deadlock the mingw
implementation might be the cause, indeed.

i see that recent qmutex.cpp has the object outside of the function.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Haunting a Windows "Subsurface not start but becoming zombie" bug

2017-04-10 Thread Thiago Macieira 
Em domingo, 9 de abril de 2017, às 16:47:25 PDT, Lubomir I. Ivanov escreveu:
> g++ test.cpp -Wall -std=c++11 -O1 -S -o test-meyer.S
> 
> so, it's guarded with ___cxa_guard_acquire() and it appears that the
> c++11 flag doesn't matter much.

That's because GCC has used thread-safe initialisation of function statics for 
a long time. I know it was specified in the IA-64 C++ ABI, dating from 1999, 
but it's possible GCC supported it for longer (3.3 or earlier).

But it wasn't part of the C++ language specification. It only said that "if the 
initialisation is reentered, behaviour is undefined". So other compilers did 
not need to implement it.

C++11 did add a requirement that such initialisation must not deadlock. This 
is known to trip several implementations. Apple operating systems are known to 
fail that second bit too.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface