Open FrostKiwi opened 3 years ago
lonkamikaze
commented
3 years ago The <charconv> header should be located under /usr/include/c++/v1/charconv. Can you verify that?
I would of course like a backtrace of the crash if you're willing to make a debug build and run it, but that requires you to be able to build it. Did you perfrom a custom WITHOUT_TOOLCHAIN install of FreeBSD?
FrostKiwi
commented
3 years ago The
<charconv>header should be located under/usr/include/c++/v1/charconv. Can you verify that?I would of course like a backtrace of the crash if you're willing to make a debug build and run it, but that requires you to be able to build it. Did you perfrom a custom WITHOUT_TOOLCHAIN install of FreeBSD?
charconv.txt No WITHOUT_TOOLCHAIN things have been done. That one's new to me. Yes it's there. Curiously though, it lacks a file extension, though maybe that's normal. Here is ls -lh /usr/include/c++/v1/
lonkamikaze
commented
3 years ago Can you go to the ports directory and run the following commands:
make -VMAKE_ENV -VMAKE_ARGSprintenvwhich c++FrostKiwi
commented
3 years ago Can you go to the ports directory and run the following commands:
* `make -VMAKE_ENV -VMAKE_ARGS` * `printenv` * `which c++`
Ohh dear, that one really was on me. To compile coreboot I needed to specify gcc6-aux in my path to get the ADA compiler gnat to work. That messed with ports.
powerdxx successfully compiles, but as before SEGFAULTS instantly upon launch.
lonkamikaze
commented
3 years ago Can you try to build the port with make -DWITH_DEBUG and produce a backtrace of the crash?
FrostKiwi
commented
3 years ago Can you try to build the port with
make -DWITH_DEBUGand produce a backtrace of the crash?
Here it is powerd++.core.tar.gz
FrostKiwi
commented
3 years ago Just for reference, with a freshly built FreeBSD 13 Kernel and a freshly FreeBSD1 3 world, the segfault still happens and makes powerdxx unusable.
FrostKiwi
commented
3 years ago @lonkamikaze Tested again today on 2 different machines. Powerdxx works for this machine:
This marks another GM45 machines, where powerdxx SEGFAULTS. This Github issue was created, because it SEGFAULTED on a Thinkpad T500. So maybe GM45 at fault? The hardware clocks were a mess with GM45 + FreeBSD so maybe that plays a role? Here is the coredump of powerdxx of with the x200 segfault: powerd++.core.gz
lonkamikaze
commented
2 years ago I found a bug with the address sanitiser, I have a vague hope that that might have been the issue: https://github.com/lonkamikaze/powerdxx/commit/28e61dbd3c5ecbb43d161729b5afb18d38f40d76
Are you willing to test this?
FrostKiwi
commented
2 years ago @lonkamikaze Thanks on following up on old issues :] Will test it.
FrostKiwi
commented
2 years ago I found a bug with the address sanitiser, I have a vague hope that that might have been the issue: 28e61db
Are you willing to test this?
Compiled from master and tested. Same deal. Instant Segmentation Fault on GM45 Laptops.
It might be unrelated, but I wanted to mention it anyways again: Manually changing dev.cpu.0.freq works but there was this hardware timer bug thingy, that prevented this CPU from going into deeper C states ( https://forums.freebsd.org/threads/c-states-not-used.66192/page-2#post-514861 / https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256261) unless you change the hardware timer. The same thing was present in DragonFlyBSD. If powerdxx does anything in that regard, querying hardware timer thingies or whatever, this might be related. Though just a shot in the dark from me...
lonkamikaze
commented
2 years ago No, it's not doing anything like that.
To use the core dumps provided I also need the binary that was run, otherwise I cannot create a backtrace.
FrostKiwi
commented
2 years ago No, it's not doing anything like that.
To use the core dumps provided I also need the binary that was run, otherwise I cannot create a backtrace.
Attached are both the binary and the coredump
lonkamikaze
commented
2 years ago This is a stripped binary, no debugging symbols, can you test a binary built with make debug paranoid? On my system the resulting binary is 5 MB large.
FrostKiwi
commented
2 years ago This is a stripped binary, no debugging symbols, can you test a binary built with
make debug paranoid? On my system the resulting binary is 5 MB large.
When building with "make debug paranoid", the resulting binary is this one: powerd++_paranoid.gz
It immediatly crashes with "Illegal Instruction" and produces no coredump.
When building with just "make debug" the resulting binary is this one: powerd++.gz
It crashes with "Segmentation Fault" and produces the following coredump: powerd++.core.gz
lonkamikaze
commented
2 years ago It's very frustrating. I cannot get a backtrace out of the coredump, there's just a single frame, not being resolved to any function and if I run the binary myself, it doesn't crash. :(
FrostKiwi
commented
2 years ago It's very frustrating. I cannot get a backtrace out of the coredump, there's just a single frame, not being resolved to any function and if I run the binary myself, it doesn't crash. :(
Then let's leave it alone and I will stick to powerd. It's very interesting though, that this affects GM45 specifically on two different laptops. "Illegal Instruction" is very suspicions. Either way, thx for your efforts. I will continue using powerd++, just not on GM45 :]
On FreeBSD 13, installing powerdxx works, but running it insta crashes:
fish: Job 1, 'sudo powerdxx' terminated by signal SIGSEGV (Address boundary error)Bash simply reports "Segmentation Fault" Building from ports results in:/usr/ports/sysutils/powerdxx/work/powerdxx-0.4.4/src/utility.hpp:8:47: fatal error: charconv: No such file or directoryHere the full log:Log from sudo make in /usr/ports/sysutils/powerdxx
`===> Building for powerdxx-0.4.4 --- powerd++.o --- --- clas.o --- --- powerd++.o --- c++ -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -std=c++17 -Wall -Werror -pedantic -c /usr/ports/sysutils/powerdxx/work/powerdxx-0.4.4/src/powerd++.cpp -o powerd++.o --- clas.o --- c++ -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -std=c++17 -Wall -Werror -pedantic -c /usr/ports/sysutils/powerdxx/work/powerdxx-0.4.4/src/clas.cpp -o clas.o --- powerd++.o --- In file included from /usr/ports/sysutils/powerdxx/work/powerdxx-0.4.4/src/Options.hpp:130:0, from /usr/ports/sysutils/powerdxx/work/powerdxx-0.4.4/src/powerd++.cpp:7: /usr/ports/sysutils/powerdxx/work/powerdxx-0.4.4/src/utility.hpp:8:47: fatal error: charconv: No such file or directory #include