Teensy loader segfault on 32-bit Linux

Status
Not open for further replies.
L

Los Frijoles

Member
I am running Arch Linux with the Xfce desktop environment. I have both gtk2 and gtk3 stuff installed and use programs built for both.

I have another 64-bit computer running Arch Linux with a nearly identical setup which does not exhibit the problem that I am about to show. The teensy loader seems to work fine (I haven't tested it on an actual teensy 3.1 yet, however). So, this problem (for now) is only showing up on 32-bit Linux for me.

I have installed the 32-bit linux teensyduino software on my locally installed copy of arduino-1.0.5 (its located in my home directory). I installed gtk-engine-murrine since it was complaining about not having it right before its segfault. With gtk-engine-murrine installed, it now only shows the segfault

Here is what I see when using Arduino IDE to load to teensy:

Code: 
Opening Teensy Loader...
Unable find Teensy Loader.  Is the Teensy Loader application running?

Running teensy manually:

Code: 
 ./teensy
Segmentation fault (core dumped)

gdb gives me the following stack trace (warning: long listing ahead):

Code: 
#0  0xb73cae05 in __longjmp_chk () from /usr/lib/libc.so.6
#1  0xb78e7364 in ?? () from /usr/lib/libgdk_pixbuf-2.0.so.0
#2  0x0819c7a3 in png_error ()
#3  0x0819f9fc in png_create_read_struct_2 ()
#4  0xb78e813b in ?? () from /usr/lib/libgdk_pixbuf-2.0.so.0
#5  0xb78d71a7 in ?? () from /usr/lib/libgdk_pixbuf-2.0.so.0
#6  0xb78d746a in gdk_pixbuf_new_from_file ()
   from /usr/lib/libgdk_pixbuf-2.0.so.0
#7  0xb7fd573c in ?? () from /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so
#8  0xb7656891 in g_cache_insert () from /usr/lib/libglib-2.0.so.0
#9  0xb7fd66e0 in ?? () from /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so
#10 0xb7fd6771 in ?? () from /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so
#11 0xb7fd3071 in ?? () from /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so
#12 0xb7fd4253 in ?? () from /usr/lib/gtk-2.0/2.10.0/engines/libpixmap.so
#13 0xb7d05d44 in gtk_paint_box () from /usr/lib/libgtk-x11-2.0.so.0
#14 0xb7cb46da in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#15 0xb7e0685f in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#16 0xb7e069c9 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#17 0xb7765693 in g_cclosure_marshal_VOID__VOID ()
   from /usr/lib/libgobject-2.0.so.0
#18 0xb7762594 in ?? () from /usr/lib/libgobject-2.0.so.0
#19 0xb7763a6e in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#20 0xb777565c in ?? () from /usr/lib/libgobject-2.0.so.0
#21 0xb777d913 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#22 0xb777dba3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#23 0xb7daa271 in gtk_widget_realize () from /usr/lib/libgtk-x11-2.0.so.0
#24 0xb7daa488 in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0
#25 0x0807c5e3 in ?? ()
#26 0xb77656e9 in g_cclosure_marshal_VOID__VOIDv ()
   from /usr/lib/libgobject-2.0.so.0
#27 0xb7762447 in ?? () from /usr/lib/libgobject-2.0.so.0
#28 0xb7763c1a in ?? () from /usr/lib/libgobject-2.0.so.0
#29 0xb777d030 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#30 0xb777dba3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#31 0xb7daa434 in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0
#32 0x0807c5e3 in ?? ()
#33 0xb77656e9 in g_cclosure_marshal_VOID__VOIDv ()
   from /usr/lib/libgobject-2.0.so.0
#34 0xb7762447 in ?? () from /usr/lib/libgobject-2.0.so.0
#35 0xb7763c1a in ?? () from /usr/lib/libgobject-2.0.so.0
#36 0xb777d030 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#37 0xb777dba3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#38 0xb7daa434 in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0
#39 0xb7dbc8f6 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#40 0xb77656e9 in g_cclosure_marshal_VOID__VOIDv ()
   from /usr/lib/libgobject-2.0.so.0
#41 0xb7762447 in ?? () from /usr/lib/libgobject-2.0.so.0
#42 0xb7763cae in ?? () from /usr/lib/libgobject-2.0.so.0
#43 0xb777d030 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#44 0xb777dba3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#45 0xb7daa434 in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0
#46 0xb7db5f0d in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#47 0xb77656e9 in g_cclosure_marshal_VOID__VOIDv ()
   from /usr/lib/libgobject-2.0.so.0
#48 0xb7762447 in ?? () from /usr/lib/libgobject-2.0.so.0
#49 0xb7763cae in ?? () from /usr/lib/libgobject-2.0.so.0
#50 0xb777d030 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#51 0xb777dba3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#52 0xb7da992a in gtk_widget_show () from /usr/lib/libgtk-x11-2.0.so.0
#53 0x08082683 in ?? ()
#54 0x080a216e in ?? ()
#55 0x08064955 in ?? ()
#56 0x0806536c in ?? ()
#57 0x0815c962 in ?? ()
#58 0x0805d35b in ?? ()
#59 0xb72e79a3 in __libc_start_main () from /usr/lib/libc.so.6
#60 0x0805c8e1 in ?? ()

Is this a known bug (assuming it is a bug and not something I am doing wrong)? Is there a fix for it that anyone knows of?

EDIT: Seeing as the segfault has something to do with libpng, I am running libpng 1.6.7
 
Last edited:
Hello there!

It seems my old laptop gets the same kind of behaviour... I am running Fedora with LXDE - I don't even know which version of Fedora, it's the only distribution I found that could display anything on the screen and not reboot after two minutes running (linux newbie here!), probably has to do with the graphics somehow ; I tried Ubuntu but it just doesn't run on this PC. Oh and of course the old Win Vista is dead on this machine too.
So here is what I get :
- when running teensy manually from the main account, I get this :
Code: 
Erreur de segmentation
i.e. segfault (nothing about dumping core on my side though)
- when running it as root, I get this before the segfault :
Code: 
(teensy:2568): IBUS-WARNING **: The owner of /home/youpeek/.config/ibus/bus is not root!

Does anyone have any clue or procedure to try out before I just go and buy a new PC? I'd rather not do that yet if it can be delayed, but then, I can't leave my new Teensy 3.1 running with just the blink running, it would be a shame!

Thanks for your help, if any!

Squeeek
 
Did you install the udev rule? That message appears to be complaining of non-root permissions. Or you could try running Teensy Loader as root....

Unfortunately, there's not much I can do to help with Fedora. I only test Teensy with Ubuntu. Usually programs for Ubuntu work on most other distros, except Arch and Gentoo. But when things do not work on the other distros, I simply can't do much to help.
 
Yes, I did install the udev rule. And, unfortunately super user power did not help saving the w... eeeh... running teensy loader, either.

Well, maybe I needed a reason to change that PC (or to get a new one at least, this one can still be used for web browsing). I'll try again in a couple of hours / days, in case the Friday the 13th or Murphy has anything to do with this. Or a PEBCAK maybe.

Thanks anyway!

Squeeek
 
PaulStoffregen said:
Can you give it a try on 32 bit Ubuntu?
Click to expand...

It works, I've tried in 14.04 and the beta version of 15.04 there's no segfault.

I'm maintaining a teensyduino package for Arch but I didn't notice the problem because I'm using x86_64. Just fired it in a 32-bit VM, indeed it faults. So far I've just tried to replace some of Arch's libraries with Ubuntu ones but it's not working yet.

I'll see tomorrow what I can find.
 
Hello,

i get "Segmentation fault" on Teensy Loader when cklci on Menu -> Help -> About
and when Menu -> File -> Open HEX File. Verbose info says:
01:57:23 PM: Teensy Loader 1.17, begin program
01:57:23 PM: Listening for remote control on port 3149
01:57:23 PM: initialized, showing main window
01:57:23 PM: HID/linux: bus "002", device "008" vid=16C0, pid=0478, ver=0103
01:57:23 PM: Device came online, code_size = 262144
01:57:23 PM: Board is: Teensy 3.1 (MK20DX256), version 1.03
01:58:26 PM: Verbose Info event
Click to expand...
OS is a OpenSuse 13.1 , 32bit and i'm a beginner on Teensy.
 
Last edited:
Hi wally,

Well at least you manage to launch Teensy Loader! Let's see if Koromix finds anything, or if someone else has any idea what we could do to provide more info to get to the issues we have.
And, if it is not possible, we'll have to switch to another OS / distro (Ubuntu is the one that has been used for the Linux validations at PJRC so it is probably the best choice), although for me it means changing the PC. Which I might be happy to do, although my account might not like is as much ^^

The story goes on!

Squeeek
 
Okay, just spent an hour on this (got home very late) and it's caused by a libpng version conflict. Ubuntu is still using libpng 1.2 while Arch (and I guess others) use the latest 1.6 versions. gdk-pixbuf2 is compiled with libpng 1.6 but ends up calling libpng functions in the teensy executable, which is statically compiled against libpng 1.2 and things go wrong after that.

On Arch 64 no problem occurs because the Teensy executable is linked dynamically to libpng12.so so the dynamic loader does not get confused.

I made it work by recompiling gdk-pixbuf2 with libpng12. I'll push a fix for my Arch package tomorrow (basically the package will provide a private build of gdk-pixbuf2 for the Teensy Loader only), and a workaround for other distributions.
 
Sigh, Linux support.

I believe the change to static linking libpng was due to problems with Gentoo using a different & incompatible libpng.

I'm open to suggestions (for 1.22 or later) on how the build might accommodate the largest number of Linux distros. Today, I actually do the compile on Ubuntu 10.4, so it links against a set of libraries that seem to work on most distros.

I only test Linux using Ubuntu 12.04 (the compile is done in a virtual machine), and sometime this summer I'm going to update to 14.04. If there's some simple build settings I can use to be more compatible with more distros, I'm open to trying. But I just can't commit to testing the Linux version on more than 1 version of Ubuntu. I'm really depending on you guys to help test other distros.
 
I think passing "-Wl,--exclude-libs,ALL" to the linker for the teensy executable should do it. It will prevent the linker from exposing the symbols pulled from static libraries. So the dynamic loader won't be able to use them for dynamic libraries down the line.

Not an expert on this stuff, but if you want to link an executable this way I'm certainly willing to test it. When you can, meanwhile I'll just work around the problem.
 
Last edited:
Hey thanks for all the time you spend on this!
@Paul don't lower the huge pile of good job you are doing, you just can't test all the existing configurations, it makes sense. I'll be happy to test whatever I can with my distribution if it can be any help (although I obviously do not have the tools and knowledge of Koromix on this topic, but having more testers is one of the keys to pointing out and then solving bugs, and I'll probably learn something on the way, which is a nice extra)
Same for Koromix, no need for excuses because you think you are late, we're talking about hours here, I often cannot get answers in my job for days or weeks, I'll be happy whenever it comes, and, if it does not come, I'll find another way ;-)
 
OK, I've solved the problem in a crude way by building a custom gdk-pixbuf2 without libpng support. I've also patched the teensy executable (using patchelf) to set RPATH to point to the directory with the custom version of gdk-pixbuf2. Setting LD_LIBRARY_PATH in a script before calling the teensy executable would work too, of course.

Here is an archive containing the necessary files. Just extract it over your arduino directory (Teensyduino 1.21):
=> (not needed anymore, see Paul's post)

You may notice that the Teensy Loaders menus show broken icons, this is normal. The toolbar icons and the background image are not affected because the loader uses a statically compiled libpng, and does not rely on gdk-pixbuf2 unlike GTK2.
 
Last edited:
It might be possible to maintain a slim dynamically-linked (normal) and a heftier statically-linked teensyduino. I don't know how many dependencies there are, but I'm guessing graphics (ie libpng) are going to be the only ones that change. Of course, then you'd have a 32-bit and 64-bit statically-linked executable. I'd probably not put the static ones one the same webpage, but rather require another click to get to.

Most people would use the dynamically-linked but static could be the fallback, when ppl report problems.

I did a search and found this. Sounds useful.
http://www.linuxfoundation.org/collaborate/workgroups/lsb/linux-application-checker-getting-started

I'm not sure how useful it would be:
http://www.phoronix-test-suite.com/
 
A fully static version would work, but it can be a pain to make it work. I don't know how much static-friendly/easy GTK and WxWidgets are. I don't think Paul wants to go down this road for what must amount to less than 0.4% of the client base :)

The problem in this case is that gdk-pixbuf2 is compiled with libpng1.6 but ends up calling the libpng 1.2 functions exposed by teensy loader. Paul has to stop the linker from exposing static library functions in the teensy executable.

"gcc -Wl,--exclude-libs,ALL" should be a good solution.
 
I tried to execute this on my ancient Fedora 14 system. I could not execute the IDE, since I have the 64-bit java installed. I was able to run the 32-bit teensy download executable (hardware/tools/teensy), and it was able to download to my Teensy-LC. Note, as reported previously, on my system, the top menu is not displayed by my gnome window manager.

Looking at it, I see a long list of dynamic libraries:
Code: 
--> ldd teensy
        linux-gate.so.1 =>  (0x0088f000)
        libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x438ae000)
        libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x437f2000)
        libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x4635c000)
        libgio-2.0.so.0 => /lib/libgio-2.0.so.0 (0x45ef4000)
        libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x436d2000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x47a8e000)
        libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x46094000)
        libfreetype.so.6 => /usr/lib/freetype-freeworld/libfreetype.so.6 (0x43636000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x43701000)
        libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0x45e11000)
        libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0x45e6e000)
        libgthread-2.0.so.0 => /lib/libgthread-2.0.so.0 (0x45e0a000)
        librt.so.1 => /lib/librt.so.1 (0x45e63000)
        libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x45cfa000)
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x4695a000)
        libSM.so.6 => /usr/lib/libSM.so.6 (0x46af0000)
        libexpat.so.1 => /lib/libexpat.so.1 (0x46010000)
        libz.so.1 => /lib/libz.so.1 (0x45ebc000)
        libdl.so.2 => /lib/libdl.so.2 (0x45cd6000)
        libusb-0.1.so.4 => /usr/lib/libusb-0.1.so.4 (0x00acf000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00917000)
        libm.so.6 => /lib/libm.so.6 (0x45e90000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4610a000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x45cdd000)
        libc.so.6 => /lib/libc.so.6 (0x45b4a000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x46158000)
        libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x43d53000)
        libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x468e8000)
        libcairo.so.2 => /usr/lib/libcairo.so.2 (0x43738000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x46a31000)
        libXrender.so.1 => /usr/lib/libXrender.so.1 (0x460ff000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0x46a44000)
        libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x46439000)
        libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x46a55000)
        libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x46a1e000)
        libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x46a19000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x45e74000)
        libselinux.so.1 => /lib/libselinux.so.1 (0x45ed3000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0x4632d000)
        /lib/ld-linux.so.2 (0x45b29000)
        libICE.so.6 => /usr/lib/libICE.so.6 (0x46a67000)
        libuuid.so.1 => /lib/libuuid.so.1 (0x46a8a000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x460df000)
        libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x468ef000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x46357000)

Now, I tend to work on the compiler and let others work on the libraries, so I'm not up on all of the details of Linux libraries. I suspect the majority of these libraries could be statically loaded, using -Bstatic before the list of libraries specified with -l, and using -Bdynamic. Note if the teensy loader is not GPL, you would need to verify that each of the libraries linked statically have the exception clause before releasing the work as part of the release (or the library uses an alternative copyright that permits static linking).

You might try using the -static-libgcc and -static-libstdc++ to make the libcc and standard C++ libraries static.

In general, you might have problems statically linking libresolve (does hostname lookups), so you would still want to link the standard C and math libraries dynamically as well as resolv. I would suspect that libselinux (which does security) also needs to be dynamically loaded..
 
Last edited:
A recompile is easy. Here it is, with "-Wl,--exclude-libs,ALL" added to the linker command:

http://www.pjrc.com/teensy/beta/teensy_loader_32bit_exclude_syms.tar.gz

Hopefully this will solve the problem?


I would love to make a fully static linked file. WxWidgets is very static linking friendly, so I already static link it. That and the images are the reason the file is a few megabytes. Years ago I looked into static linking the other stuff. I found a number of well written explanations that all said the same thing: GTK and the many related libraries are pretty much designed in a way that makes static linking impossible. Edit: and Michael's point is also relevant... many of those libs probably don't permit static linking in their license, so there's non-technical issues too.

Linux is indeed a tiny portion of the total user base, and it currently takes 2 of the 4 builds. But what Linux lacks in simplicity, it (usually) makes up for with a very skilled and enthusiastic user base and solid technical documentation. I consider source code I can figure out in an hour as documentation.

With all 3 systems, the limiting factor is human factors: useful feedback and willingness to test beta releases. Linux is clearly the best in that regard. Windows is by far the hardest system!
 
Last edited:
Hi everybody!

I tested both versions, they worked very well! You just saved my budget (and myself from the gentle wrath of my girlfriend huh) ;-)
Here are some more details :
- Koromix's version : I got this kind of errors in the shell (./teensy loaded manually) : (teensy:3205):
Code: 
GdkPixbuf-CRITICAL **: gdk_pixbuf_get_XXX: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
-- replace XXX with diefferent items to fetch from the pixbuf object, e.g. pixels_with_length, width, height.
- Paul's version : nothing in the shell. Please note that, before I tested your version, I renamed the gdk-pixbuf2 folder in the lib (which was created by Koromix's patch) to make sure the link was not solved because I had both versions "inter-patched"

Let me know if you need more testing !

And thanks again for all you're doing (not just today for that troublesome Linux newbie with a PC that has a will of its own)!

Squeeek
 
squeeek said:
Koromix's version : I got this kind of errors in the shell (./teensy loaded manually) : (teensy:3205):
Code: 
GdkPixbuf-CRITICAL **: gdk_pixbuf_get_XXX: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
-- replace XXX with diefferent items to fetch from the pixbuf object, e.g. pixels_with_length, width, height.
Click to expand...

Yeah, it's because mine was a hack that worked by castrating gdk-pixbuf2. Now that Paul relinked the loader, I suggest dumping it into a black hole or /dev/null :)
 
Status
Not open for further replies.
Back
Top