Segfault on arm using nightly rust 1.6 about rust_minifb HOT 33 CLOSED

Thanks for the report. Which platform is this on (I have Raspberry Pi 2 at home which I could try to repro this on)

It seems that either this call

https://github.com/emoon/rust_minifb/blob/master/src/native/x11/X11MiniFB.c#L90

Fails or that the code actually doesn't get there.

from rust_minifb.

It's an Odroid C1.

from rust_minifb.

Regarding your last comment.

Have you tested to run the example that is included? Is that when you get the crash or is it when you use it somewhere else?

from rust_minifb.

I have only tried it as part of rust64. Give me a sec to try the example as well.

from rust_minifb.

That being said I'm not actually sure how Cargo deals which multiple versions of libs.

from rust_minifb.

Ok, I think I see the problem now - minifb is still using libc v0.1.12 which is why the hack that should work against libc 0.2 segfaults when paired with libstd from rust 1.6 (your example segfaults in exactly the same way after hacking minifb first)

from rust_minifb.

And with libc 0.2 it still crashes?

from rust_minifb.

After a mechanical update it does unfortunately.

Program received signal SIGSEGV, Segmentation fault.
0x7f5599a0 in mfb_update (buffer=0xbef1dc54) at src/native/x11/X11MiniFB.c:128
128             s_ximage->data = (char*)buffer;
(gdb) bt
#0  0x7f5599a0 in mfb_update (buffer=0xbef1dc54) at src/native/x11/X11MiniFB.c:128
#1  0x7f55944c in minifb::update (buffer=...) at src/lib.rs:53
#2  0x7f558070 in noise::main () at examples/noise.rs:17
#3  0x7f561708 in thread::catch_panic::h5646355977087970433 ()
#4  0x7f561238 in rt::lang_start::h7706ba8a97b5a83c71x ()
#5  0x7f558674 in main ()

from rust_minifb.

alright, I think it fails on this call

https://github.com/emoon/rust_minifb/blob/master/src/native/x11/X11MiniFB.c#L90

For some reason. Without having access to the hardware it's hard to debug it. If you in gdb shows the value of s_ximage (it should be a proper value, and not 0) that would be great.

from rust_minifb.

(gdb) print  s_ximage
$1 = (XImage *) 0x0

from rust_minifb.

So that call fails for some reason... Oh well. I guess I should order a Odroid C1 so I can fix the issue :)

from rust_minifb.

You mean it doesn't reproduce on Rpi2? I believe the problem is purely about those C bindings so you should be fine without spending anything.

And BTW, if you wanted a real step up you should definitely get a XU4 which in retrospect I'd buy today.

from rust_minifb.

I haven't actually tried it on Rpi 2 so I should do that.

I also notice some bad code,

https://github.com/emoon/rust_minifb/blob/master/src/lib.rs#L41

This only checks for 0 but I see that I return -1 in some cases in https://github.com/emoon/rust_minifb/blob/master/src/native/x11/X11MiniFB.c#L21

which is bad so there might be some call that fails earlier for some reason.

And BTW, if you want a real step up you should definitely get a XU4 which in retrospect I'd buy today.

Ok. That one seems pretty cool so will get one of those :)

from rust_minifb.

Cool, the difference is definitely worth the money (and 2GB of ram is a hit).

Quick rust links for the Pi:
https://sothr.com/RustBuild/armv6-armhf/rust/nightly/latest
https://sothr.com/RustBuild/armv6-armhf/cargo/nightly/latest

from rust_minifb.

Thanks!

I will try to test it during the weekend.. Also I plan to move over the C code to Rust also and make sure errors are reported back earlier (the library hasn't been released on creates.io yet for a reason :)

from rust_minifb.

Hi again,

How's your rust on arm experience been so far? :)

from rust_minifb.

Hi, I got the hardware but I haven't got around to use it yet :( I hope to get going with it during next week.

from rust_minifb.

Hi. I tested today and I have updated quite a bit of the code but nothing that should really change anything and it works for me.

Can you tested with the latest code and see if it works?

from rust_minifb.

You mean it works for you on Rpi, right?

from rust_minifb.

It works on the Odroid XU4

from rust_minifb.

Oh, great; I'll get back to you with the result a little later.

from rust_minifb.

thanks! :)

from rust_minifb.

I tried a quick cargo run --example noise and it didn't segfault but I'm using 16bpp so I got:

Unable to find 32-bit format for X11 display
Unable to create window Unable to open Window

On Odroid C1 a reboot is necessary to change colour depth unfortunately, so that will have to wait until tomorrow. Hope you like your XU4 ;)

from rust_minifb.

Cool. Thanks for testing :) Yeah, I have added more checks so there shouldn't be any crashes but some logging on what goes wrong.

from rust_minifb.

Closing this now as it seems to work with 32/24-bit

from rust_minifb.

You should definitely have a look at glshim, one of the coolest projects for ARM devices! The parent project's author is the one to follow whereas ptitSeb's fork is the most usable.

from rust_minifb.

Cool. My goal with minifb was really to not require any 3D accelerator and only use 2D APIs (while OS may still use 3D accel under the hood I don't of course care about) but for ARM devices it likely makes sense to setup a OpenGL context instead.

That being said minifb is more of a prototyping lib which is supposed to make it easy to just get something up and running and likely never will be as complete compared to SDL for example.

from rust_minifb.

On most ARM devices you'd be using the native OpenGL ES - I mentioned glshim cause it's a hacking masterpiece.

If you want to see how powerful your XU4 is doing the translations try this. You'll need to compile glshim first and put it in your LD_LIBRARY_PATH

from rust_minifb.

Cool. But In my case I could just use OpenGL ES right? I I mean I only need to put a 32-bit buffer on the screen (so I really only need to update a texture from the CPU side) and I guess OpenGL ES should support that?

from rust_minifb.

Yes, definitely, forget about accelerated OpenGL on most arm devices (unless you owned an NVIDIA Tegra board) - I quipped about glshim thinking you might like the hackery behind it (it's GL 1.5 only).

The OpenGL you have available is just soft-rendered MESA so from now on, it should always be the nativeGLES/EGL for ya! :)

from rust_minifb.

Right :) Well for my use-case that is fine.

from rust_minifb.

One cool library lunixbochs wrote is called tinygles - it's a pure software implementation so maybe you could use some ideas from it.

from rust_minifb.

Cool. Thanks!

from rust_minifb.