Dear all,
After some hours of searching and digging, I'm despate enough to ask for help. I think the problem is too complex to get specific answers. But perhaps someone can give me some hints as to how to find out more …
Three years ago I wrote a small tool for PocketBook ereaders (see here). And if I use the ARM-binary from it's latest version, the tool still works without any problems.
But if I compile it now, even with the exact same code (and deps) from the latest version, it crashes immediately on the device. Unfortunately, there is no error message or whatsoever.
What the program does:
- Ask if the task should be performed (dialog)
- Do the work (update a database etc.)
- Show information
As I said, the program terminates immediately. You don't even see the initial dialog. But when I remove the work part (which runs only after the users answers the dialog with "yes"), the dialog is shown. How can this be? I guess it's not possible to write something into a file, when a program crashes, is it? Because currently I have no information what could be wrong. Any ideas?
Thanks a lot
Martin
Sorry, just one stupid idea: When it is an embedded device with restricted memory resources, the new binary could be too large to fit into memory, or cause something like stack overflow or whats ever? Does the code contain unsafe blocks? I think personally I would try different builds, not only debug and release builds, but try also other built option combinations. I have still no experience in systematic debugging, for me the fact that Rust programs runs typically without any issues is one of the reason why I am currently using Rust
Any chance you can run it with gdb on the arm machine? I think that's the simplest way forward.
Otherwise, I'd try to reproduce a similar working build
Try compiling with --locked using the Cargo.lock file from the last working build 3 years ago.
My first idea was, too, that it has something to do with the size (stack overflow or whatever).
What I did now is to move away from the cross-compiler I have used (a linaro package) and tried to use the toolchain from the manufacturer. In the end, it worked. I still have to tell it where to find the libraries (LD_LIBRARY_PATH), but at least it works. But why it behaved so strangely - no idea.