Closed GoogleCodeExporter closed 9 years ago
Please build a debug version of the latest trunk using the following command:
make clean debug
Then provide the error call stack of this debug version.
Original comment by j...@cp-lab.com
on 6 Apr 2012 at 8:51
There is nothing more, the popup says:
Access violation
---
The error details has been copied to the clipboard.
---
$00007F258058D6F1
But all that's in the clipboard is
Access violation
$00007F258058D6F1
and this is what's in the shell:
TApplication.HandleException Access violation
Stack trace:
$00007FB26B8A26F1
Access violation
$00007FB26B8A26F1
Is there something I need to pass to the transgui executable to get it to dump
a stack trace?
Thanks!
Original comment by varbanse...@gmail.com
on 6 Apr 2012 at 12:13
The error occurs in some external lib, that's why the call stack is not
available. transgui uses GTK2 widgetset, double check the gtk2 libs.
Also check if other gtk2 apps works.
Original comment by j...@cp-lab.com
on 6 Apr 2012 at 12:20
This works fine: http://www.peazip.org/download-linux-gtk2-portable.html
What libraries are part of the gtk2 widgetset? Here are the gtk packages
installed on my system
i A fp-units-gtk-2.6.0
i A fp-units-gtk2-2.6.0
i A gir1.2-gtk-3.0
i gtk-theme-switch
i gtk2-engines
i gtk2-engines-oxygen
i gtk2-engines-qtcurve
i ia32-libs-gtk
i kde-config-gtk-style
i A lazarus-ide-gtk2-0.9.30.2
i A lcl-gtk2-0.9.30.2
i libcanberra-gtk3-0
i libcanberra-gtk3-module
i libdbusmenu-gtk3-4
i libdbusmenu-gtk4
i libgpod4-nogtk
i libgtk-3-0
i A libgtk-3-bin
i A libgtk-3-common
i libgtk2-perl
i libgtk2.0-0
i libgtk2.0-0-dbg
i libgtk2.0-bin
i libgtk2.0-common
i A libgtk2.0-dev
i A libgtkmm-2.4-1c2a
i A libgtkspell0
i libjavascriptcoregtk-1.0-0
i libnm-gtk-common
i libnm-gtk0
i libwebkitgtk-1.0-0
i libwebkitgtk-1.0-common
i libwxgtk2.8-0
i A python-aptdaemon.gtk3widgets
i python-gtk2
i A python-wxgtk2.8
i software-properties-gtk
Original comment by varbanse...@gmail.com
on 6 Apr 2012 at 12:46
It looks like the issue is from the use ssl option for a connection, if I
tunnel trough and disable the option I can connect to the transmission instance
without a problem.
What libraries are used for the ssl functionality?
Original comment by varbanse...@gmail.com
on 6 Apr 2012 at 12:52
So it seems that libssl-1.0.0 moved the libraries from /usr/lib to
/usr/lib/x86_64-linux-gnu for a 64 bit debian and that seems to break your
code. I installed libssl-0.9.8 as well and it works fine now.
libssl-0.9.8 is no longer in sid so you might want to fix that or at least
handle the exception better?
Original comment by varbanse...@gmail.com
on 6 Apr 2012 at 1:53
Thanks for the investigation.
transgui first tries to load libssl.so.0.9.8 and libcrypto.so.0.9.8 libs. If
they not found then libssl.so and libcrypto.so are used.
Do you have libssl.so and libcrypto.so symlinks somewhere?
Original comment by j...@cp-lab.com
on 6 Apr 2012 at 3:06
The only one I found is in /usr/lib/x86_64-linux-gnu/
It doesn't look like libssl-0.9.8 setup any generic libssl.so links.
Original comment by varbanse...@gmail.com
on 6 Apr 2012 at 3:12
transgui works with any openssl version. Do you have libssl.so and libcrypto.so
symlinks by default with openssl 1.0?
Original comment by j...@cp-lab.com
on 6 Apr 2012 at 3:21
Yes, and here is the output from ldconfig showing the libssl.so and
libcrypto.so references are correct and exist (this is with libssl-0.9.8
removed)
ldconfig -p | grep libssl
libssl3.so.1d (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl3.so.1d
libssl3.so.1d (libc6) => /usr/lib32/libssl3.so.1d
libssl3.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl3.so
libssl3.so (libc6) => /usr/lib32/libssl3.so
libssl.so.1.0.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
libssl.so.0.9.8 (libc6, hwcap: 0x0008000000008000) => /usr/lib32/i686/cmov/libssl.so.0.9.8
libssl.so.0.9.8 (libc6, hwcap: 0x0004000000000000) => /usr/lib32/i586/libssl.so.0.9.8
libssl.so.0.9.8 (libc6, hwcap: 0x0002000000000000) => /usr/lib32/i486/libssl.so.0.9.8
libssl.so.0.9.8 (libc6) => /usr/lib32/libssl.so.0.9.8
libssl.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so
ldconfig -p | grep libcrypto
libcrypto.so.1.0.0 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
libcrypto.so.0.9.8 (libc6, hwcap: 0x0008000000008000) => /usr/lib32/i686/cmov/libcrypto.so.0.9.8
libcrypto.so.0.9.8 (libc6, hwcap: 0x0004000000000000) => /usr/lib32/i586/libcrypto.so.0.9.8
libcrypto.so.0.9.8 (libc6, hwcap: 0x0002000000000000) => /usr/lib32/i486/libcrypto.so.0.9.8
libcrypto.so.0.9.8 (libc6) => /usr/lib32/libcrypto.so.0.9.8
libcrypto.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libcrypto.so
libcrypto++.so.9 (libc6,x86-64) => /usr/lib/libcrypto++.so.9
I wonder if the libssl.so.0.9.8 link to the 32bit libraries is causing the
problem? Does your code check for arch compatibility?
Original comment by varbanse...@gmail.com
on 6 Apr 2012 at 3:27
Fixed in r740. Please test.
Original comment by j...@cp-lab.com
on 7 Apr 2012 at 1:34
It works now, thanks!
Looking at the code you will have this issue again later when the libssl
version changes.
Some google search results suggest that the 32bit libssl-0.9.8 provided by the
ia32-libs package could be the cause of the error. Apparently the LoadLibrary
call would either throw the Access Violation error when attempting to load the
32bit library or when you try to use it. In either case some error handling
around the LoadLibrary call and when you try to use it might be a more
permanent solution.
Thanks again for your work, it's a very helpful tool!
Original comment by varbanse...@gmail.com
on 7 Apr 2012 at 2:01
The error has been caused by passing NULL handle to the FreeLibrary(). It is
not related to 32-bit libs. Now the code has been changed to avoid AV error.
The proper error message about missing OpenSSL libs will be displayed.
Original comment by j...@cp-lab.com
on 7 Apr 2012 at 2:11
Original comment by j...@cp-lab.com
on 7 Apr 2012 at 2:39
Original issue reported on code.google.com by
varbanse...@gmail.com
on 6 Apr 2012 at 1:23