Hi, Sorry for the long time to answer, but I had no time to dig into this.
On Thu, Nov 06, 2014 at 10:40:39PM +0100, hikaru.deb...@web.de wrote: > > Hmm, it's a strange thing. If I recompile fso-deviced eveything works as > > expected. > > But you can reproduce the problem with the packages as they are in > Debian right now? > I just rebuild the Jessie package (armhf) and still get the same > startup error (as I expected). I can verify, that the binary is broken (and thus the init script fails, too). > > It seems, the generated .c files from vala-sources are broken. > > Unfortunately this is above my skills. Please let me know if I can be of any > further assistance in solving this! starting the binary without the init script tells us: $ sudo fsodeviced *** stack smashing detected ***: fsodeviced terminated [...] Which means, that there is a stack based buffer overflow. I could trace the problem to the Kernel.InputDevice constructor method, which is kernel_input_device_construct() in the plugin.c I guess Rico does not use the "-fstack-protector-strong" gcc parameter, so in his build setup the binary does not verify if the stack has been corrupted. Stuff I tried so far to find the stack problem: * comparing the generated C code from current vala with the pregenerated C code from FSO: problem has not been introduced by newer vala! * reading through the C code to find the stack problem: could not find it! * runing binary without -fstack-protector-strong in valgrind: nothing found in the Kernel.InputDevice constructor * building without -O2: works * build using clang-3.5 without changing CFLAGS/LDFLAGS still broken * build using clang-3.5 + address sanitizer: problem gone :( [it would have traced the error] So I think I will enable "-fno-stack-protector" in the package for now. -- Sebastian
signature.asc
Description: Digital signature
