Heh, funny. I have no problem with xbindkeys, starts and runs fine, but I get this with tilda instead:
tilda[5737]: segfault at 0 ip 080501fb sp bfe26300 error 4 in tilda[8048000+14000]
Rebuilding didn't help either.

I am unable to reproduce this on my machines, which are all i686-based. Peter, are your three machines running x86_64? Preliminary googling suggests this might be an x86_64 specifc issue.

All of my machines are i686.

Are you using a customized .xbindkeysrc? If so, have you tried removing it to see if it successfully loads without it?

If that fixes the problem, post the config here and we'll see what's what.

I've included a 5 second sleep before starting xbindkeys, in gnome-session-manager. Since this, I no longer have a problem.
Here is my config:
"/home/muczy/bin/start-firefox.sh"
c:180

"/home/muczy/bin/start-firefox.sh"
b:9

"gnome-terminal"
c:133

Well, I'm glad you got it working. I've never seen such short keybinds before--typically they are two parts such as "m:0x10 + c:134".

Before I close this bug, could you rename .xbindkeysrc to something else, start the utility without a 5 second delay and then post your results? I'm curious to know whether this could be a syntax-related error--though it does sound like it's related to load order.

I think, some xorg-related update solved my problem... On my second machine, I don't use this 5 second sleep, and it's working fine since xorg 1.5 update. I'm gonna delete the 5 sec sleep at my first machine, and write the results here.

Well I've tried it on the first machine, and it works without the 5 sec sleep. So some update solved it for me...

That's great and I appreciate the update...I'll consider that a wrap for now then.

Cheers

Another segfault today:
xbindkeys[2801]: segfault at 4 ip b7f77031 sp bfe70b40 error 4 in libX11.so.6.2.0[b7f4c000+eb000]

For the record: I fixed my tilda segfaults; empty config file was the culprit.

Peter, I do suspect this is related to your ~/.xbindkeysrc as well. A couple of questions to help get the ball rolling...

How are you launching xbindkeys? If it's by a startup script such as ~/.xinitrc, can you please attach that file.

Regarding the config you posted above, can you please attach the entire file?

Can you verify that the keycodes above (c:180, b:9, c:133) are in fact what are displayed (in totality) when you execute 'xbindkeys -mk' and press those keys?

I launch it via gnome-session-manager. xbindkeys -mk says (I did press the two buttons, didn't hold alt/shift/ctrl):
"(Scheme function)"
m:0x2050 + c:133
Mod2+Mod4 + Super_L
"(Scheme function)"
m:0x2050 + c:134
Mod2+Mod4 + Super_R
But if I set e.g. m:0x2050 + c:133 in my config, it simply doesn't work.
Which is pasted above, is my whole config file.

I really don't know what else to suggest. I've looked at dozens of xbindkeysrc files and not one of them uses a single keycode syntax the way yours is configured. For that matter, I've never seen a modifier keycode so long either.

What I have been able to assess is that similar segfault behaviour has been reported in the wild by a few others, and it was found to be due to an improperly configured rc file. The fact that your config does not conform to any others, leads me to believe this is the cause of your segfaults as well.

Edit: Actually, I do have a couple suggestions...

1.) Kill xbindkeys, then launch it from a terminal with 'xbindkeys -v' and look for any relevant messages

2.) Set your keycodes to the same codes suggested by 'xbindkeys -k' and see whether it segfaults (regardless of whether your scripts actually execute)

3.) Send your keyboard make/model and config info upstream to the xbindkeys developer (hocwp at free dot fr). Perhaps the input device is generating codes that xbindkeys cannot process currently.