Re: wxWidgets alert at start - Mailing list pgadmin-hackers

I soon get used to the fact that I changed my subscriber email,
setting it right helps in getting the message through. If this is a
double, feel free to erase this (as always)!

On 2.8.2007, at 23.20, Dave Page wrote:

> Jyrki Wahlstedt wrote:
>> Hmm, I'm not sure, whether the situation improved. What happens is
>> that
>> the app crashes twice. I wouldn't bet it is better :-)
>
> OK, last time I checked once an app had crashed it couldn't crash
> again
> unless it was restarted!! What happens *exactly*, including error
> message text?
>
Ok, I could hardly believe my eyes with this. After 'make install' I
write the command 'open pgAdmin3.app', after a while I get wxWidgets
debug alert, identical to the one I had previously. An instant later
I get the crashdump dialog about unexpected quit, and if I choose
'Report…', I get this:
Thread 0 Crashed:
0   org.postgresql.pgadmin             0x0022638d isPgApp(wxString
const&) + 189 (misc.cpp:1098)
1   org.postgresql.pgadmin             0x00009d60 pgAdmin3::InitPaths()
+ 4342 (pgAdmin3.cpp:766)
2   org.postgresql.pgadmin             0x00010a02 pgAdmin3::OnInit() +
704 (pgAdmin3.cpp:208)
3   org.postgresql.pgadmin             0x002e0f0a
wxAppConsole::CallOnInit() + 24 (app.h:76)
4   ...x_base_carbonud-2.8.0.dylib     0x17d65a46 wxEntry(int&,
wchar_t**) + 52 (init.cpp:433)
5   org.postgresql.pgadmin             0x00008278 main + 24
(pgAdmin3.cpp:104)
6   org.postgresql.pgadmin             0x00007b76 _start + 216
7   org.postgresql.pgadmin             0x00007a9d start + 41

and an instant later:
Thread 0 Crashed:
0   ...x_base_carbonud-2.8.0.dylib     0x17d85bdd wxStringBase::find
(wxStringBase const&, unsigned long) const + 23 (string.h:412)
1   ...x_base_carbonud-2.8.0.dylib     0x17d8753c wxStringBase::find
(wchar_t const*, unsigned long, unsigned long) const + 62 (string.cpp:
495)
2   ...x_base_carbonud-2.8.0.dylib     0x17d875c2 wxString::Find(wchar_t
const*) const + 40 (string.cpp:1681)
3   org.postgresql.pgadmin             0x002eb03e wxString::Contains
(wxString const&) const + 32 (pgConn.cpp:1272)
4   org.postgresql.pgadmin             0x002263b1 isPgApp(wxString
const&) + 225 (misc.cpp:1098)
5   org.postgresql.pgadmin             0x00009d60 pgAdmin3::InitPaths()
+ 4342 (pgAdmin3.cpp:766)
6   org.postgresql.pgadmin             0x00010a02 pgAdmin3::OnInit() +
704 (pgAdmin3.cpp:208)
7   org.postgresql.pgadmin             0x002e0f0a
wxAppConsole::CallOnInit() + 24 (app.h:76)
8   ...x_base_carbonud-2.8.0.dylib     0x17d65a46 wxEntry(int&,
wchar_t**) + 52 (init.cpp:433)
9   org.postgresql.pgadmin             0x00008278 main + 24
(pgAdmin3.cpp:104)
10  org.postgresql.pgadmin             0x00007b76 _start + 216
11  org.postgresql.pgadmin             0x00007a9d start + 41

I shouldn't have said that the app crashed twice, but superficially
it looks something like that.
>
>> In cases like this I'm always inclined to think that I myself have
>> done
>> something stupid. Now I just don't know what it could be. The output
>> from SharedSupport/helper/pg_dump is:
>> jwa@bach:pgadmin3> cd pgAdmin3.app/Contents/SharedSupport/helper/
>> jwa@bach:helper> otool -L pg_dump
>> pg_dump:
>>         @executable_path/../../../Contents/Frameworks/libpq.5.dylib
>> (compatibility version 5.0.0, current version 5.0.0)
>>         @executable_path/../../../Contents/Frameworks/libssl.
>> 0.9.8.dylib
>> (compatibility version 0.9.8, current version 0.9.8)
>>
>> @executable_path/../../../Contents/Frameworks/libcrypto.0.9.8.dylib
>> (compatibility version 0.9.8, current version 0.9.8)
>>
>> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
>> (compatibility version 5.0.0, current version 5.0.0)
>>         @executable_path/../../../Contents/Frameworks/libz.1.dylib
>> (compatibility version 1.0.0, current version 1.2.3)
>>
>> @executable_path/../../../Contents/Frameworks/libreadline.5.2.dylib
>> (compatibility version 5.0.0, current version 5.2.0)
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
>> current
>> version 88.3.9)
>>
>> Looks ok to me
>
> OK, but what if you then run otool on each of those libs that are
> in the
> bundle? Perhaps one of them is referencing something thats not
> there (or
> the build script broke a reference).
Here's the output:
jwa@bach:Frameworks> for l in libcrypto.0.9.8.dylib libpq.5.dylib
libreadline.5.2.dylib libssl.0.9.8.dylib libz.1.dylib ; do
 >   echo $l
 >   otool -L $l
 > done
libcrypto.0.9.8.dylib
libcrypto.0.9.8.dylib:
         libcrypto.0.9.8.dylib (compatibility version 0.9.8, current
version 0.9.8)
         @executable_path/../../Contents/Frameworks/libz.1.dylib
(compatibility version 1.0.0, current version 1.2.3)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.9)
libpq.5.dylib
libpq.5.dylib:
         libpq.5.dylib (compatibility version 5.0.0, current version
5.0.0)
         @executable_path/../../Contents/Frameworks/libssl.
0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
         @executable_path/../../Contents/Frameworks/libcrypto.
0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
         /System/Library/Frameworks/Kerberos.framework/Versions/A/
Kerberos (compatibility version 5.0.0, current version 5.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.9)
libreadline.5.2.dylib
libreadline.5.2.dylib:
         libreadline.5.2.dylib (compatibility version 5.0.0, current
version 5.2.0)
         @executable_path/../../Contents/Frameworks/libncurses.
5.dylib (compatibility version 5.0.0, current version 5.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.6)
libssl.0.9.8.dylib
libssl.0.9.8.dylib:
         libssl.0.9.8.dylib (compatibility version 0.9.8, current
version 0.9.8)
         @executable_path/../../Contents/Frameworks/libcrypto.
0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
         @executable_path/../../Contents/Frameworks/libz.1.dylib
(compatibility version 1.0.0, current version 1.2.3)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.9)
libz.1.dylib
libz.1.dylib:
         libz.1.dylib (compatibility version 1.0.0, current version
1.2.3)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.6)
jwa@bach:Frameworks>

I then copied the /opt/local/lib libraries over and verified that the
app works. I looked at otool output:
jwa@bach:Oddlibs> otool -L libpq.5.dylib ../Frameworks/libpq.5.dylib
libpq.5.dylib:
         libpq.5.dylib (compatibility version 5.0.0, current version
5.0.0)
         @executable_path/../../Contents/Frameworks/libssl.
0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
         @executable_path/../../Contents/Frameworks/libcrypto.
0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
         /System/Library/Frameworks/Kerberos.framework/Versions/A/
Kerberos (compatibility version 5.0.0, current version 5.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.9)
../Frameworks/libpq.5.dylib:
         /opt/local/lib/postgresql82/libpq.5.dylib (compatibility
version 5.0.0, current version 5.0.0)
         /opt/local/lib/libssl.0.9.8.dylib (compatibility version
0.9.8, current version 0.9.8)
         /opt/local/lib/libcrypto.0.9.8.dylib (compatibility version
0.9.8, current version 0.9.8)
         /System/Library/Frameworks/Kerberos.framework/Versions/A/
Kerberos (compatibility version 5.0.0, current version 5.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.9)

The same output from your build is:
jwa@bach:Frameworks> otool -L libpq.5.dylib
libpq.5.dylib:
         libpq.5.dylib (compatibility version 5.0.0, current version
5.0.0)
         /usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7,
current version 0.9.7)
         /usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7,
current version 0.9.7)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.3)

There are minor differences, but at least I can't see anything
significant.
>
>> The configure phase behaves now well, as expected. Thanks! There is,
>> however, one slightly odd thing. In the summary there is a statement
>> telling that SSL support is missing based probably on:
>> checking for SSL_connect in -lpq... no
>> checking for krb5_free_principal in -lpq... no
>>
>> This is certainly true in a way, as those symbols are not defined in
>> libpq, but in libssl and libkrb5, respectively, but they do exist,
>> both
>> libraries and symbols (checked with nm -g).
>
> That works OK for me. It's just checking for the symbol in the lib
> which
> is only there if it's linked with openssl (whether or not it's an
> imported or exported symbol isn't relevant to us - just whether
> it's there).
>
> Regards, Dave

Thanks for the clarification!

!
! Jyrki Wahlstedt
!    http://www.wahlstedt.fi/jyrki/
!
! Our life is no dream; but it ought to become one and perhaps will.
! PGP key ID: 0x139CC386 fingerprint: F355 B46F 026C B8C1 89C0  A780
6366 EFD9 139C C386