A board of inquiry investigated the causes of the explosion and in two weeks issued a report. It turned out that the cause of the failure was a software error in the inertial reference system. Specifically a 64 bit floating point number relating to the horizontal velocity of the rocket with respect to the platform was converted to a 16 bit signed integer. The number was larger than 32,767, the largest integer storeable in a 16 bit signed integer, and thus the conversion failed.
A.k.a. the Ariane disaster. Be careful with conversions, else your rocket could explode :P
The C++ front end has experimental support for all of the current C++17 draft with the -std=c++1z or -std=gnu++1z flags, including if constexpr, class template argument deduction, auto template parameters, and structured bindings. For a full list of new features, see the C++ status page.
So perhaps you’re trying to use -std=c++17 in a version that doesn’t support it,
which is causing it to fall back to -std=gnu++11?
Same thing with 2048.bin or pokitto-puzzles firmware.bin
(gdb) where #0 0x00007ffff7165337 in std::locale::~locale() () from /lib64/libstdc++.so.6 #1 0x00007ffff71b8dba in std::basic_ifstream<char, std::char_traits<char> >::~basic_ifstream() () from /lib64/libstdc++.so.6 #2 0x000000000040535b in loadBin(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) [clone .cold.3] () #3 0x0000000000000000 in ?? ()
EDIT: Weird. I hacked the PokittoEmu loadBin function to use FILE* functions instead of ifstream. It works now. Wonder why ifstream fails?
I know you’ll probably need to know the details, I’ve told the person to come join us here, so let’s see
Anyway, the interesting part is that changing ifstream to the other file API makes it work.
I tested the latest code from the repo and no crashes for me.
I’m going to go out on a limb and say it’s probably a bug in the specific implementation of std::locale::~locale().
A crash coming from a destructor is a bad sign.
That usually implies that it’s trying to dispose of a resource that’s already been disposed of.
Most of the time you get a segfault from dereferencing a pointer that’s either nullptr or not pointing to a valid object.
(Segfault’s a bad name really, I think it ought to be called a RAM access violation.)
I think so, I’m thinking he might have fiddled with the libraries and have a bad installation or using headers for the wrong version or something. We probably won’t know without more details about the OS etc.
For my text editor I am trying to access SD, and disk_initialize() hangs the emulator, but not Pokitto.
EDIT:
I dunno if I’m using it correctly, should I rather use FileIO? It’s weird, in master branch there is only a simulator version of this lib, while in other branches there is also a HW version. Is it WIP?
SD card support is still a bit rough. To make it work you need an SD card image.
Don’t make an image that is too big, the entire file is loaded into RAM so make sure to allocate just what you need, not 128gb.
Once you have a formatted image, run the emulator like this: PokittoEmu game.bin -I card.img
With this you should be able to read from the SD. Support for writing has an issue I’m still working on.
Hi,
I’m quite sure it has been already asked so be patient.
I’d like to know if can be possibile to attach a debugger to Pokitto Emulator from VS Code (platformio) or Embitz from windows.
I see PokittoEmu support GDB debugging but I don’t know what is need to complete the setup.
Ideally I’d like to write software in VS Code, then (pushing a shortcut) build and deploy to PokittoEmu, attaching source code to allow breakpoints, step by step execution and watching variables. Is this possibile?
With our own plugin, yes.
Even with hardware the Cortex plugin isn’t as seamless as I’d like.
I might have another solution for this problem soonish, I hope. I just moved to Portugal so this week has been really crazy. Hopefully I’ll be able to get back to coding soon. On the good side, I’m now on a similar timezone to you guys.