'Segmentation fault' only on Raspbian

[Oliv']

Hi !

I am trying to use Mbrola, a TTS software and I have a surprising behavior :
I can see help files with '-h' argument, the software complains well if arguments are not corrects, but crashes with a 'segmentation fault' when I try to use it.
The most surprising is that it works well with the Debian image from 17/02/2012.

Does anybody have an idea ? Thanks

If the strace could help:

Code: Select all

execve("/usr/bin/mbrola", ["mbrola", "/usr/share/mbrola/voices/fr1", "bonjour.ph
o", "test.wav"], [/* 17 vars */]) = 0
brk(0)                                  = 0x3ff000
uname({sys="Linux", node="raspberrypi", ...}) = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40
008000
access("/etc/ld.so.preload", R_OK)      = 0
open("/etc/ld.so.preload", O_RDONLY)    = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
mmap2(NULL, 44, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0x400ff000
close(3)                                = 0
open("/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\10\4\0\0004\0\0\0"..., 5
12) = 512
lseek(3, 3456, SEEK_SET)                = 3456
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1
240) = 1240
lseek(3, 2537, SEEK_SET)                = 2537
read(3, "A.\0\0\0aeabi\0\1$\0\0\0\0056\0\6\6\10\1\t\1\n\2\22\4\24\1\25"..., 47) 
= 47
fstat64(3, {st_mode=S_IFREG|0755, st_size=7332, ...}) = 0
mmap2(NULL, 35276, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x401
3b000
mprotect(0x4013c000, 28672, PROT_NONE)  = 0
mmap2(0x40143000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRIT
E, 3, 0) = 0x40143000
close(3)                                = 0
munmap(0x400ff000, 44)                  = 0
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=39707, ...}) = 0
mmap2(NULL, 39707, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4009c000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/arm-linux-gnueabihf/libm.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\3201\0\0004\0\0\0"..., 5
12) = 512
lseek(3, 426468, SEEK_SET)              = 426468
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1
160) = 1160
lseek(3, 426136, SEEK_SET)              = 426136
read(3, "A0\0\0\0aeabi\0\1&\0\0\0\0056\0\6\6\10\1\t\1\n\2\22\4\24\1\25"..., 49) 
= 49
fstat64(3, {st_mode=S_IFREG|0644, st_size=427628, ...}) = 0
mmap2(NULL, 458912, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40
144000
mprotect(0x401ac000, 28672, PROT_NONE)  = 0
mmap2(0x401b3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRIT
E, 3, 0x67) = 0x401b3000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\230y\1\0004\0\0\0"..., 5
12) = 512
lseek(3, 1190688, SEEK_SET)             = 1190688
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1
360) = 1360
lseek(3, 1190252, SEEK_SET)             = 1190252
read(3, "A.\0\0\0aeabi\0\1$\0\0\0\0056\0\6\6\10\1\t\1\n\2\22\4\24\1\25"..., 47) 
= 47
fstat64(3, {st_mode=S_IFREG|0755, st_size=1192048, ...}) = 0
mmap2(NULL, 1201448, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4
01b5000
mmap2(0x402d5000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRI
TE, 3, 0x120) = 0x402d5000
mmap2(0x402d8000, 9512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOU
S, -1, 0) = 0x402d8000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40
0b8000
set_tls(0x400b84c0, 0x400b8b98, 0x400fb048, 0x400b84c0, 0x400fb048) = 0
mprotect(0x402d5000, 8192, PROT_READ)   = 0
mprotect(0x401b3000, 4096, PROT_READ)   = 0
mprotect(0x400fa000, 4096, PROT_READ)   = 0
munmap(0x4009c000, 39707)               = 0
brk(0)                                  = 0x3ff000
brk(0x420000)                           = 0x420000
open("/usr/share/mbrola/voices/fr1", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=5080000, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40
049000
read(3, "MBROLA2.060\20\5\0\0\361O\0\0\200AM\0\200>x\1a\0a\0d"..., 4096) = 4096
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

[plugwash]

Where did you get this software from? was it source or binary? if binary was source available?

[Oliv']

Hi, I took it from the Mbrola website (there) but unfortunatly there is only a binary, sources are not availables

[itimpi]

Hi, I took it from the Mbrola website (there) but unfortunatly there is only a binary, sources are not availables

Odds on that bianry is not compatible with the Raspbian hardfp ARM build. As a general principle picking up binaries for a package is very rarely going to work on a the Pi.

[Oliv']

Odds on that bianry is not compatible with the Raspbian hardfp ARM build. As a general principle picking up binaries for a package is very rarely going to work on a the Pi.

So it works on the debian package because floatting points were not computed in hardware ?
Is there any workaround for these kind of situations ?

By the way, I'll contact the developpers and ask them if an ARMv6 hardfp build is possible.

Thanks

[plugwash]

So it works on the debian package because floatting points were not computed in hardware ?

What matters is not how floating point calculations are done per-se but how floating point parameters are passed to functions.

the gcc "-mfloat-abi=" setting has three possible values. "soft" makes the compiler use software floating point and pass floating point values in integer registers (or on the stack when integer registers run out). "softfp" makes the compiler use hardware floating point but it still passes floating point values in integer registers (or on the stack when integer registers run out) which is inefficent (AIUI moving values between floating point and integer registers is relatively slow). "hard" makes the compiler use hardware floating point and pass floating point values in floating point registers (or on the stack when floating point registers run out).

"soft" and "softfp" are compatible with each other but are not compatible with "hard".

Is there any workaround for these kind of situations ?

You can create an armel chroot and run your binary in that. How practical this is will depend on what your program is doing.

By the way, I'll contact the developpers and ask them if an ARMv6 hardfp build is possible.

If they are prepared to do it that would be the best outcome.

[Oliv']

Thank you for your explanations, it helped me

You can create an armel chroot and run your binary in that. How practical this is will depend on what your program is doing.

I didn't know about debootsrap and chroot but that seems to be useful in many other situations, and works in this case !!! Thank you

I'll try to contact developers to have a native build, it will be a smarter solution but your workaround works fine.

[kbailey]

I had chromium running flawlessly after formatting and installing a 4gb image onto a 4 GB SD card. I worked till I got the config for speed and display size and rebooted. Doring this time I installed iceweasel and chromium, and both worked fine.

I rebooted after all this, and tried to run chromium, which would not run. I th4en tried to launch from root terminal, and saw a text error "segmentation fault". Hmmm...

OK now gang, say what? Same code, same machine. Had the system go back ans swallow up all available space. NOT using berryboot. Sayhuh?