Hi Hans,
Could we please get Pd-extended to link the "pd" executable to libstdc++.so ? Afaik, this is a fix for a possibly wide category of problems but that is currently only "known" to affect GridFlow when loading GEM while the driver named "fglrx" is in use (ATI video).
AFAIK, this problem affects any lib that uses the "throw" keyword in C++ code, whenever the ATI driver is loaded _before_ the standard library of C++, in which case it will provide its own version of a portion of the C++ standard library, which is incompatible (sort of like the DLL Hell on Windows). This driver is typically loaded by anything linked to OpenGL directly or indirectly (usually GEM, but could also be 3DP, OpenSceneGraph, etc)
So, what I'm asking, is to link Pd itself to a library that it doesn't need, in order to force the bug out, so that this problem doesn't have to be addressed anywhere else. I believe that it is far easier to prevent this bug from the Pd executable than to make any kind of elaborate circus with the loading-order of pdsettings and pdrc and a little dummy .pd_linux (which has -lstdc++ without using it, and has an empty _setup).
If you want, you can think of it as the first step for putting GridFlow in pd-extended.
diff from Claude:
------------------8<--------cut-here--------8<------------------ --- pd-0.41-4/src/makefile.in.orig 2008-03-15 00:03:00.000000000 +0000 +++ pd-0.41-4/src/makefile.in 2009-08-23 18:55:35.000000000 +0100 -121,7 +121,7 @@ $(CC) $(CFLAGS) $(STRIPFLAG) -o $(BIN_DIR)/pdreceive u_pdreceive.c
$(PDEXEC): $(OBJ) $(BIN_DIR) - cd ../obj; $(CC) $(LDFLAGS) $(DBG_CFLAGS) -o $(PDEXEC) $(OBJ) $(LIB) + cd ../obj; $(CC) $(LDFLAGS) $(DBG_CFLAGS) -o $(PDEXEC) $(OBJ) $(LIB) -lstdc++
$(BIN_DIR)/pd-gui: $(GOBJ) $(GSRC) cd ../obj; $(CC) $(INCLUDE) -o $(BIN_DIR)/$(GUINAME) $(GOBJ) $(GLIB) ------------------8<--------cut-here--------8<------------------
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Hey Matju,
From my perspective, adding -lstdc++ has more problems than just making a simple libstdc++.pd_linux and loading that. For example, the Debian package will then require libstdc++. Plus it means another difference from Pd-vanilla. Its not really something I know about, and therefore would not be a candidate for maintaining it. Someone else would have to step up on that front. The libstdc++.pd_linux could easily be included with Gridflow. Or using the libdir format like Gem perhaps, where it loads a shared library first as part of the process of loading the lib.
Do you have any documentation on this as a suggested workaround?
.hc
On Aug 23, 2009, at 2:30 PM, Mathieu Bouchard wrote:
Hi Hans,
Could we please get Pd-extended to link the "pd" executable to libstdc++.so ? Afaik, this is a fix for a possibly wide category of problems but that is currently only "known" to affect GridFlow when loading GEM while the driver named "fglrx" is in use (ATI video).
AFAIK, this problem affects any lib that uses the "throw" keyword in C++ code, whenever the ATI driver is loaded _before_ the standard library of C++, in which case it will provide its own version of a portion of the C++ standard library, which is incompatible (sort of like the DLL Hell on Windows). This driver is typically loaded by anything linked to OpenGL directly or indirectly (usually GEM, but could also be 3DP, OpenSceneGraph, etc)
So, what I'm asking, is to link Pd itself to a library that it doesn't need, in order to force the bug out, so that this problem doesn't have to be addressed anywhere else. I believe that it is far easier to prevent this bug from the Pd executable than to make any kind of elaborate circus with the loading-order of pdsettings and pdrc and a little dummy .pd_linux (which has -lstdc++ without using it, and has an empty _setup).
If you want, you can think of it as the first step for putting GridFlow in pd-extended.
diff from Claude:
------------------8<--------cut-here--------8<------------------ --- pd-0.41-4/src/makefile.in.orig 2008-03-15 00:03:00.000000000 +0000 +++ pd-0.41-4/src/makefile.in 2009-08-23 18:55:35.000000000 +0100 -121,7 +121,7 @@ $(CC) $(CFLAGS) $(STRIPFLAG) -o $(BIN_DIR)/pdreceive u_pdreceive.c
$(PDEXEC): $(OBJ) $(BIN_DIR)
cd ../obj; $(CC) $(LDFLAGS) $(DBG_CFLAGS) -o $(PDEXEC) $(OBJ) $(LIB)
cd ../obj; $(CC) $(LDFLAGS) $(DBG_CFLAGS) -o $(PDEXEC) $(OBJ) $(LIB) -lstdc++
$(BIN_DIR)/pd-gui: $(GOBJ) $(GSRC) cd ../obj; $(CC) $(INCLUDE) -o $(BIN_DIR)/$(GUINAME) $(GOBJ) $ (GLIB) ------------------8<--------cut-here--------8<------------------
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
----------------------------------------------------------------------------
Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra
Hans-Christoph Steiner wrote:
Do you have any documentation on this as a suggested workaround?
http://wiki.fifengine.de/Segfault_in_cxa_allocate_exception#Workaround_.231
"Explicitly linking against libstdc++ before linking against the opengl libraries resolves this issue!"
You can have an external (in fact, I use one[1]) that links libstdc++, and load it into Pd before anything else, which "works" - but it's much more fragile and hoop-jumping for users who just want something that works, how many times can you debug ~/.pdsettings or ~/.pdrc for users who don't care why C++ exceptions cause crashes when they use Gem or whatever...
[1] https://code.goto10.org/svn/maximus/pd-libstdcpp/
Claude
On Aug 23, 2009, at 8:14 PM, Claude Heiland-Allen wrote:
Hans-Christoph Steiner wrote:
Do you have any documentation on this as a suggested workaround?
http://wiki.fifengine.de/Segfault_in_cxa_allocate_exception#Workaround_.231
"Explicitly linking against libstdc++ before linking against the opengl libraries resolves this issue!"
You can have an external (in fact, I use one[1]) that links libstdc+ +, and load it into Pd before anything else, which "works" - but it's much more fragile and hoop-jumping for users who just want something that works, how many times can you debug ~/.pdsettings or ~/.pdrc for users who don't care why C++ exceptions cause crashes when they use Gem or whatever...
Wouldn't you need to use this libstdcpp.pd_linux external for Pd vanilla anyway?
.hc
----------------------------------------------------------------------------
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Claude Heiland-Allen wrote:
Hans-Christoph Steiner wrote:
Do you have any documentation on this as a suggested workaround?
http://wiki.fifengine.de/Segfault_in_cxa_allocate_exception#Workaround_.231
"Explicitly linking against libstdc++ before linking against the opengl libraries resolves this issue!"
You can have an external (in fact, I use one[1]) that links libstdc++, and load it into Pd before anything else, which "works" - but it's much more fragile and hoop-jumping for users who just want something that works, how many times can you debug ~/.pdsettings or ~/.pdrc for users who don't care why C++ exceptions cause crashes when they use Gem or whatever...
hmm, does this mean that if Gem explicitely linked against libstdc++ just before libGL, this would avoid the problems?
if so, it might be fixed in svn...
fgasdr IOhannes
On Tue, 8 Sep 2009, IOhannes m zmoelnig wrote:
hmm, does this mean that if Gem explicitely linked against libstdc++ just before libGL, this would avoid the problems? if so, it might be fixed in svn...
Thanks for doing this. I just tried it with Pd-0.42.5-extended-20091014-ubuntu-jaunty-i386.deb.
It may still fail if any other extern (3DP, OSG, ...) ever links with libGL before libstdc++, while being loaded before GEM or instead of GEM.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard wrote:
On Tue, 8 Sep 2009, IOhannes m zmoelnig wrote:
hmm, does this mean that if Gem explicitely linked against libstdc++ just before libGL, this would avoid the problems? if so, it might be fixed in svn...
Thanks for doing this. I just tried it with Pd-0.42.5-extended-20091014-ubuntu-jaunty-i386.deb.
cool (i guess you not only meant to say that you tried it, but also that the try was successfull)
It may still fail if any other extern (3DP, OSG, ...) ever links with libGL before libstdc++, while being loaded before GEM or instead of GEM.
yes. as a matter of fact, the ATI-drivers should be fixed.
since Gem depends on stdc++ anyhow, i thought i might pull it in before libGL, so there is virtually no overhead involved.
with any pure C external (like 3dp), this approach seems very ugly.
fgmadsr IOhannes
On Thu, 15 Oct 2009, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
Thanks for doing this. I just tried it with Pd-0.42.5-extended-20091014-ubuntu-jaunty-i386.deb.
cool (i guess you not only meant to say that you tried it, but also that the try was successfull)
Oh. Yes. But I didn't try it with the fglrx libGL. (see below)
It may still fail if any other extern (3DP, OSG, ...) ever links with libGL before libstdc++, while being loaded before GEM or instead of GEM.
yes. as a matter of fact, the ATI-drivers should be fixed.
In the end, it's not really an ATI-driver bug, because:
1. i discovered the bug on my computer that has a non-ATI graphics card, and couldn't get rid of the bug afterwards. I don't know what I did. the Xorg driver is called "intel", not "fglrx". I won't reinstall the OS to see whether I still have the bug that way. The crash is still related to loading libGL in particular in that case.
2. the root cause of the bug is always an incompatibility between different versions of gcc. there is no actual bug in the ATI source. there's nothing really wrong with ATI's source and makefiles. it's a GCC bug that propagated in ATI's binaries. Because I have the bug on my computer too, it also propagated into other binaries, it seems. But really, back then, it wasn't a bug yet, because the problem is one of forward-compatibility: the exception-system startup code of gcc 3.x has to support gcc 4.x, but doesn't, because of a change in gcc starting with 4.x...
that's the info i could get from researching on my computer, web/google, and asking some people on IRC, and then putting everything together. but i'm not Sherlock Holmes, so it's not elementary to me, and i'm not sure i got everything right.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard wrote:
On Thu, 15 Oct 2009, IOhannes m zmoelnig wrote:
Mathieu Bouchard wrote:
Thanks for doing this. I just tried it with Pd-0.42.5-extended-20091014-ubuntu-jaunty-i386.deb.
cool (i guess you not only meant to say that you tried it, but also that the try was successfull)
Oh. Yes. But I didn't try it with the fglrx libGL. (see below)
It may still fail if any other extern (3DP, OSG, ...) ever links with libGL before libstdc++, while being loaded before GEM or instead of GEM.
yes. as a matter of fact, the ATI-drivers should be fixed.
In the end, it's not really an ATI-driver bug, because:
i discovered the bug on my computer that has a non-ATI graphics card, and couldn't get rid of the bug afterwards. I don't know what I did. the Xorg driver is called "intel", not "fglrx". I won't reinstall the OS to see whether I still have the bug that way. The crash is still related to loading libGL in particular in that case.
the root cause of the bug is always an incompatibility between different versions of gcc. there is no actual bug in the ATI source. there's nothing really wrong with ATI's source and makefiles. it's a GCC bug that propagated in ATI's binaries. Because I have the bug on my computer too, it also propagated into other binaries, it seems. But really, back then, it wasn't a bug yet, because the problem is one of forward-compatibility: the exception-system startup code of gcc 3.x has to support gcc 4.x, but doesn't, because of a change in gcc starting with 4.x...
that's the info i could get from researching on my computer, web/google, and asking some people on IRC, and then putting everything together. but i'm not Sherlock Holmes, so it's not elementary to me, and i'm not sure i got everything right.
thanks for doing the research. i still believe that this is something that is not to be fixed with hacks, e.g. random linkeage against stdc++. instead it should be fixed somewhere upstream, be it gcc, binary drivers or whatever; btw. who is writing drivers in C++?
(C++-externals like Gem don't do "random linking" against stdc++ since they require it anyhow)
fgmasrd IOhannes
On Thu, 15 Oct 2009, IOhannes m zmoelnig wrote:
i still believe that this is something that is not to be fixed with hacks, e.g. random linkeage against stdc++. instead it should be fixed somewhere upstream, be it gcc, binary drivers or whatever; btw. who is writing drivers in C++? (C++-externals like Gem don't do "random linking" against stdc++ since they require it anyhow)
I don't know what it is that you call «random linkage». either you say "-lstdc++" and it sets the order of "-lstdc++" in the linkage list, or else you don't say it but it appears anyway as "-lstdc++" implicitly because you used "g++" as the compiler name instead of "gcc".
I can tell you that doing ldd on every version of Gem.pd_linux on my computer, new or old, says it is linked to libstdc++.
It is definitely not your usual linkage problem and it evaded several times my logical reasoning about it, because I was making usual suppositions. But the problem is not one of symbol resolution, it's about the initialisation order of a global singleton, where only one version of the initialiser gets run...
Yes, it is ultimately GCC's fault, but they won't fix it because they can't fix it because it's just too late and they can't do anything about it now that wouldn't make the problem more complicated, and then they wouldn't be able to propagate the fix because the problem has been bundled with a zillion linux distros before anyone realised that it was gonna be a problem (?).
I know you are referring to the usual idea that something called a "driver" wouldn't be written in C++, but not only those driver-writers don't care about all the tradition and peer-pressure against writing "drivers" in C++, but also, those drivers have nothing to do with the Linux kernel, so it's pretty much outside of that culture. Afaik those video drivers are made of one-half XFree-format drivers, and one-half ELF-SO format drivers, so, it's 100% userspace.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
Mathieu Bouchard wrote:
On Thu, 15 Oct 2009, IOhannes m zmoelnig wrote:
i still believe that this is something that is not to be fixed with hacks, e.g. random linkeage against stdc++. instead it should be fixed somewhere upstream, be it gcc, binary drivers or whatever; btw. who is writing drivers in C++? (C++-externals like Gem don't do "random linking" against stdc++ since they require it anyhow)
I don't know what it is that you call «random linkage». either you say "-lstdc++" and it sets the order of "-lstdc++" in the linkage list, or else you don't say it but it appears anyway as "-lstdc++" implicitly because you used "g++" as the compiler name instead of "gcc".
I can tell you that doing ldd on every version of Gem.pd_linux on my computer, new or old, says it is linked to libstdc++.
It is definitely not your usual linkage problem and it evaded several times my logical reasoning about it, because I was making usual suppositions. But the problem is not one of symbol resolution, it's about the initialisation order of a global singleton, where only one version of the initialiser gets run...
sorry for the confusion. with "random linkeage" i was referring to e.g. Pd-extended or 3dp linking with "-lstdc++". these are pure C (any 3dpers forgive me, if 3dp is actually written in C++; i assume it is not), and should, imho, not link against stdc++.
any library written in C++ of course has to link against it. making sure that a binary uses the libstdc++ it was compiled with is totally valid; therefore i have added an explicit linking to Gem that should pull in libstdc++ before anyhting else (like a driver) can pull in a wrong version of it. i consider this a good idea (esp. if it fixes the problem)
fgmasdr IOhannes
On Thu, 15 Oct 2009, IOhannes m zmoelnig wrote:
sorry for the confusion. with "random linkeage" i was referring to e.g. Pd-extended or 3dp linking with "-lstdc++". these are pure C (any 3dpers forgive me, if 3dp is actually written in C++; i assume it is not), and should, imho, not link against stdc++.
Well, all those shouldnots are somehow supposing that anything else that shouldn't happen is not happening. So in the end we get stuck with everybody else problems AND a long list of all the solutions we shouldn't use. So in the end, we end up having to tell the users to not move Gem away from the top of pdsettings/pdrc lest they pay the price for it, when there are more global solutions for it that could fix the problem forever. I wouldn't really advocate that 3DP or whatever else would link to -lstdc++ because then it doesn't fix the problem that people just can't reorder their pdsettings/pdrc lines as they please. So I'd rather link pd itself with libstdc++, and although it doesn't make any sense when trying to follow all rules, it does make perfect sense when you consider that to compensate from rules that have been broken you may as well break more rules. The problem is with a variable that is global to the whole pd process anyway, so with a certain logic, pd itself is the right place to fix the problem.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
On Sun, 23 Aug 2009, Hans-Christoph Steiner wrote:
From my perspective, adding -lstdc++ has more problems than just making a simple libstdc++.pd_linux and loading that. For example, the Debian package will then require libstdc++.
Requiring libstdc++ isn't what I call a «problem».
If you mean the Pd-extended package that includes Gem... it already requires libstdc++ since a long time. I can't find an old Pd-extended debfile on my computer that doesn't list libstdc++ as a dependency.
maintaining it. Someone else would have to step up on that front. The libstdc++.pd_linux could easily be included with Gridflow. Or using the libdir format like Gem perhaps, where it loads a shared library first as part of the process of loading the lib.
Actually, I can't get the linking problem solved just by messing around with the GridFlow linkage. I can't seem to fix the problem by linking anything statically. It seems to be about whatever libstdc++ is started first, no matter whether it's linked statically inside a certain libGL, or linked dynamically from anywhere on the system. It boots the "try/catch" system used by the whole process, and then a "throw" compiled with a new gcc doesn't work with an old "try/catch" system, no matter how old is the compiler that compiled the "try/catch" commands. This is as far as I could guess what's going on.
The bug may come back in the future, but if you always load libdir and Gem at the beginning of the loadlib list, then it will not come back (or else, it would be a different bug, certainly!).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801
-
Claude Heiland-Allen -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard