test.cpp: Crash with w64devkit...

[xparq]

Nothing with MSVC and CLANG on WSL2. Nothing with g++ on WSL2, either!
Only with g++ on the 64-bit version of w64devkit.
Also with IPROF_DISABLE_VECTOR_OPT! (Note don't forget to define it twice then: both in test.cpp and iprof.cpp!... Which is so stupid, worth its own issue...)
Also with -O2 (not just -O3).
Also with the prev. 4 commits (oldest tried: 32d3934)! :-o Something is really off here... I'd swear this didn't happen with any of them earlier! Even with the fresh ones today, it was all right for quite a while.
But: OK with d5e596c!

WTF?! And now with 32d3934, too, again! AND 4805a35! ?!?!?! AND WITH THE MOST RECENT ONE, TOO!!! What the hell is going on?!

• Wow!... :-o If the tmp. project dir (for testing the old commits) was in a subdir called _old_, it comiled all right. As soon as renaming it to _last_ (or _oldx_), it crashed! :D Fantastic... If GCC puts the full path into the exe for some reason, there should be an off-by-one error somewhere... And this can also explain the mysterious slowdown mentioned in a later issue comment: either some unexpected misalignment, or that off-by-one error did something already without actually crashing... IT'S CRAZY!

  • However...:
    • Couldn't find that _out_ in the exe... (Could be UCS-16 or something, but browsed it through, seen other 16-bit strings, but not the path.)
    • It's too robust: -O2 vs. -O3 makes no difference, despite the size differences (but this is not conclusive: can be random, and (more likely) O2 vs O3 may not affect it, only some data (segment/region) size.

UPDATE:

Definitely an alignment issue: couldn't reproduce it with renaming the main prj (work tree) dir at first: iprof -> iprof1 did nothing. Neither did iprof12. But iprof123 did! :-o It "fixed" the crash!... :-o

---

FTW, the crash:
>gdb a.exe Reading symbols from a.exe...

warning: could not convert 'main' from the host encoding (CP65001) to UTF-32.
This normally should not happen, please file a bug report.
(gdb) r
Starting program: a.exe
[New Thread 23768.0x7530]
sizeof(iProf::TagList): 128 bytes

And the lucky double is: 440.835

The profiler stats so far:
SCOPE: AVG_TIME (TOTAL_TIME / TIMES_EXECUTED)
All times in micro seconds
heavyCalc: 3.33874e+06 μs (3338737 μs / 1)
heavyCalc/bigWave: 539.615 μs (539615 μs / 1000)
heavyCalc/hugePower: 2798.49 μs (2798489 μs / 1000)
heavyCalc/hugePower/Interm.: 2797.3 μs (2797305 μs / 1000)
heavyCalc/hugePower/Interm./FirstPowerLoop: 604.288 μs (604288 μs / 1000)
heavyCalc/hugePower/Interm./SecondPowerLoop: 562.654 μs (562654 μs / 1000)
heavyCalc/hugePower/Interm./BigWavePowerLoop: 1629.42 μs (1629422 μs / 1000)
heavyCalc/hugePower/Interm./BigWavePowerLoop/bigWave: 542.846 μs (1628539 μs / 3000)

Second lucky double is 440.835

The profiler stats after the second run:
heavyCalc: 3.33854e+06 μs (6677079 μs / 2)
heavyCalc/bigWave: 539.271 μs (1078542 μs / 2000)
heavyCalc/hugePower: 2798.61 μs (5597211 μs / 2000)
heavyCalc/hugePower/Interm.: 2797.8 μs (5595600 μs / 2000)
heavyCalc/hugePower/Interm./FirstPowerLoop: 605.265 μs (1210530 μs / 2000)
heavyCalc/hugePower/Interm./SecondPowerLoop: 561.518 μs (1123036 μs / 2000)
heavyCalc/hugePower/Interm./BigWavePowerLoop: 1630.06 μs (3260129 μs / 2000)
heavyCalc/hugePower/Interm./BigWavePowerLoop/bigWave: 543.053 μs (3258320 μs / 6000)

Let's try a multithreaded environment
[New Thread 23768.0x59ac]
[New Thread 23768.0x5ff8]
440.835

Thread 4 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 23768.0x5ff8]
0x00007ff6b6ef7dee in std::map<LossyVector<char const*, 15u>, iProf::Totals, std::less<LossyVector<char const*, 15u> >, std::allocator<std::pair<LossyVector<char const*, 15u> const, iProf::Totals> > >
::~map() ()

[xparq]

FTR. I also noticed earlier another w64devkit weirdness: test times all of a sudden almost tripled!

Either I actually remember wrong, and they always took way too long, or something happened that made them last more than 10 seconds, while all others are at around 3-4!

[xparq]

There's not much I can do about it, so... I can still reopen it later, if it becomes relevant again.