glibc detected *** free(): invalid pointer:
We have at least 3 bugs in the tracker with this crash on startup (just search the tracker for "glibc"). Does anyone know what's going on? Is this fixed in 42.1?
Quoting bulia byak <buliabyak@...400...>:
We have at least 3 bugs in the tracker with this crash on startup (just search the tracker for "glibc"). Does anyone know what's going on?
So far, they all seem to be binary incompatibilities.
Is this fixed in 42.1?
Not really much we can do...
-mental
On 8/11/05, mental@...3... <mental@...3...> wrote:
Quoting bulia byak <buliabyak@...400...>:
We have at least 3 bugs in the tracker with this crash on startup (just search the tracker for "glibc"). Does anyone know what's going on?
So far, they all seem to be binary incompatibilities.
Is this fixed in 42.1?
Not really much we can do...
So can we close all these bugs? Can you provide a more detailed comment so that bug reporters can get an idea of what to do?
Quoting bulia byak <buliabyak@...400...>:
So can we close all these bugs? Can you provide a more detailed comment so that bug reporters can get an idea of what to do?
I guess.
Basically the only solution is to use a build of Inkscape for their specific distribution and version, assuming they haven't upgraded a lot of libraries and things from the base version.
Otherwise they're probably best off building it themselves. Or using the autopackage, possibly.
-mental
On Thu, Aug 11, 2005 at 07:00:56PM -0400, mental@...3... wrote:
Quoting bulia byak <buliabyak@...400...>:
So can we close all these bugs? Can you provide a more detailed comment so that bug reporters can get an idea of what to do?
I guess.
Basically the only solution is to use a build of Inkscape for their specific distribution and version, assuming they haven't upgraded a lot of libraries and things from the base version.
This is one reason (although not a great reason) for having distro-specific (or glibc-specific) rpms.
I believe that it is possible to do a glibc detection as part of the rpm install; this may be a cleaner way of resolving the issue - just make the rpm fail to install if it's being installed against the wrong glibc.
Bryce
On 8/11/05, Bryce Harrington <bryce@...1...> wrote:
This is one reason (although not a great reason) for having distro-specific (or glibc-specific) rpms.
Sigh.
I'm not saying we shouldn't make distro-specific rpms if it's really necessary. But it still does not look like something normal and acceptable, to me.
I believe that it is possible to do a glibc detection as part of the rpm install; this may be a cleaner way of resolving the issue - just make the rpm fail to install if it's being installed against the wrong glibc.
Sounds like a good workaround. Anyone sufficiently RPM-savvy to set this up?
At least, can you tell me exactly which version(s) of glibc our static rpms require?
On Thu, Aug 11, 2005 at 10:52:23PM -0300, bulia byak wrote:
On 8/11/05, Bryce Harrington <bryce@...1...> wrote:
This is one reason (although not a great reason) for having distro-specific (or glibc-specific) rpms.
Sigh.
I'm not saying we shouldn't make distro-specific rpms if it's really necessary. But it still does not look like something normal and acceptable, to me.
Well, you may not accept death or the IRS either. ;-) Fact is, this is exactly the issue that many, many ISVs face with Linux today.
A good third of the people at OSDL are working on projects related to this specific issue. The idea of a single binary package that installs cleanly on any Linux system is a holy grail of the industry.
I believe that it is possible to do a glibc detection as part of the rpm install; this may be a cleaner way of resolving the issue - just make the rpm fail to install if it's being installed against the wrong glibc.
Sounds like a good workaround. Anyone sufficiently RPM-savvy to set this up?
If it were me, I'd probably start by examining the RPM spec file for netscape, acrobat reader, or opera.
At least, can you tell me exactly which version(s) of glibc our static rpms require?
Probably 2.3.4.
bryce@...957... ~ $ ldd /usr/bin/inkscape | grep libc libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0xb74e8000) libc.so.6 => /lib/libc.so.6 (0xb6f4a000) bryce@...957... ~ $ ls -l /lib/libc.so.6 lrwxrwxrwx 1 root root 13 Jul 12 23:42 /lib/libc.so.6 -> libc-2.3.4.so
Bryce
On Thu, 11 Aug 2005 17:43:11 -0700, Bryce Harrington wrote:
This is one reason (although not a great reason) for having distro-specific (or glibc-specific) rpms.
Bryce, this isn't a glibc issue, it's almost certainly a C++ ABI incompatibility. Since we started statically linking GTKmm into the autopackages I have not seen this error.
Can anybody give more info about this?
On 8/26/05, Mike Hearn <mike@...869...> wrote:
Can anybody give more info about this?
Here are the bugs:
http://sourceforge.net/tracker/index.php?func=detail&aid=1246364&gro... http://sourceforge.net/tracker/index.php?func=detail&aid=1166320&gro...
I think there was one more but I can't find it now. You can try asking the submitters for more info.
On Fri, 26 Aug 2005 13:07:27 -0300, bulia byak wrote:
Here are the bugs:
http://sourceforge.net/tracker/index.php?func=detail&aid=1246364&gro... http://sourceforge.net/tracker/index.php?func=detail&aid=1166320&gro...
I think there was one more but I can't find it now. You can try asking the submitters for more info.
It's GCC bug #21405 again, aka "multiple C++ ABIs were thought to be parallel installable but in fact were not". The first report is too vague to be useful but in the second we can see the reporters problem clearly: he has SCIM loaded as a GTK+ module which is implemented in C++.
The only solution is to use a "native ABI" binary. Once autopackage 1.2 is out it will take care of ensuring that automatically, for now I can only suggest that people experiencing these crashes compile Inkscape themselves.
thanks -mike
participants (4)
-
unknown＠example.com -
Bryce Harrington -
bulia byak -
Mike Hearn