I was using a new Rescan feature with a specified block height, it triggered a "Segmentation fault", though yesterday I used the same feature/block height. For now just to not forget, I will debug later.
I was using a new Rescan feature with a specified block height, it triggered a "Segmentation fault", though yesterday I used the same feature/block height. For now just to not forget, I will debug later.
For coredumps, run ulimit -c unlimited to make sure your shell will generate coredumps and then run the application which coredumps. In the Olden Times Linux would always make the "core" file in the same dir as the binary that makes it. But I have now seen that some new Linux distributions put them in weird places, for instance Arch puts them in /var/lib/systemd/coredump
Once you have a coredump file (which is usually called "core" or "core.XYZ" where XYZ is the PID that generated it) you can then type gdb binary_name core_filename and then type bt to generate the backtrace. We should have this info written down somewhere in our dev docs because it comes up often.
For coredumps, run `ulimit -c unlimited` to make sure your shell will generate coredumps and then run the application which coredumps. In the Olden Times Linux would always make the "core" file in the same dir as the binary that makes it. But I have now seen that some new Linux distributions put them in weird places, for instance Arch puts them in /var/lib/systemd/coredump
Once you have a coredump file (which is usually called "core" or "core.XYZ" where XYZ is the PID that generated it) you can then type `gdb binary_name core_filename` and then type `bt` to generate the backtrace. We should have this info written down somewhere in our dev docs because it comes up often.
It actually seems the coredump can happen when you are not rescanning, any time you are importing privkeys. This coredump happened even though I disabled rescanning.
Here is a partial backtrace (all the rest of it is deep QT internals stuff)
Core was generated by `./silentdragonx'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f4e7d02a601 in QLineEdit::text() const () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
[Current thread is 1 (Thread 0x7f4e79402bc0 (LWP 2938296))]
(gdb) bt
#0 0x00007f4e7d02a601 in QLineEdit::text() const () at /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#1 0x0000000000445ba1 in MainWindow::importPrivKey()::$_15::operator()() const::{lambda(QJsonValue)#1}::operator()(QJsonValue) const
(this=0x28bc3e0, response=...) at src/mainwindow.cpp:1323
#2 0x0000000000445956 in std::_Function_handler<void (QJsonValue), MainWindow::importPrivKey()::$_15::operator()() const::{lambda(QJsonValue)#1}>::_M_invoke(std::_Any_data const&, QJsonValue&&) (__functor=..., __args=...)
at /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:300
#3 0x000000000052deab in std::function<void (QJsonValue)>::operator()(QJsonValue) const (this=0x28d0370, __args=...)
at /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:688
#4 0x00000000005272eb in Connection::doRPC(QJsonValue const&, std::function<void (QJsonValue)> const&, std::function<void (QNetworkReply*, QJsonValue const&)> const&)::$_16::operator()() const (this=0x28d0340) at src/connection.cpp:943
It seems like the bug is in QT itself, maybe we can change our code to not trigger it. The above happened with QT 5.12.8
It actually seems the coredump can happen when you are not rescanning, any time you are importing privkeys. This coredump happened even though I disabled rescanning.
Here is a partial backtrace (all the rest of it is deep QT internals stuff)
```
Core was generated by `./silentdragonx'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f4e7d02a601 in QLineEdit::text() const () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
[Current thread is 1 (Thread 0x7f4e79402bc0 (LWP 2938296))]
(gdb) bt
#0 0x00007f4e7d02a601 in QLineEdit::text() const () at /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#1 0x0000000000445ba1 in MainWindow::importPrivKey()::$_15::operator()() const::{lambda(QJsonValue)#1}::operator()(QJsonValue) const
(this=0x28bc3e0, response=...) at src/mainwindow.cpp:1323
#2 0x0000000000445956 in std::_Function_handler<void (QJsonValue), MainWindow::importPrivKey()::$_15::operator()() const::{lambda(QJsonValue)#1}>::_M_invoke(std::_Any_data const&, QJsonValue&&) (__functor=..., __args=...)
at /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:300
#3 0x000000000052deab in std::function<void (QJsonValue)>::operator()(QJsonValue) const (this=0x28d0370, __args=...)
at /usr/bin/../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/std_function.h:688
#4 0x00000000005272eb in Connection::doRPC(QJsonValue const&, std::function<void (QJsonValue)> const&, std::function<void (QNetworkReply*, QJsonValue const&)> const&)::$_16::operator()() const (this=0x28d0340) at src/connection.cpp:943
```
It seems like the bug is in QT itself, maybe we can change our code to not trigger it. The above happened with QT 5.12.8
For coredumps, run ulimit -c unlimited to make sure your shell will generate coredumps and then run the application which coredumps. In the Olden Times Linux would always make the "core" file in the same dir as the binary that makes it. But I have now seen that some new Linux distributions put them in weird places, for instance Arch puts them in /var/lib/systemd/coredump
On Debian 12 it is in the same directory as well.
> For coredumps, run `ulimit -c unlimited` to make sure your shell will generate coredumps and then run the application which coredumps. In the Olden Times Linux would always make the "core" file in the same dir as the binary that makes it. But I have now seen that some new Linux distributions put them in weird places, for instance Arch puts them in /var/lib/systemd/coredump
>
On Debian 12 it is in the same directory as well.
As another data point, the coredump does not seem to happen every time. I was testing and was importing one valid privkey and usually a few invalid privkeys at a time. I only got this coredump one time in about 10 imports and all imports had rescanning disabled. All valid imports I was testing with were taddr privkeys.
If somebody hits this coredump and can provide a backtrace, please also add this data:
How many valid/invalid privkeys were being imported?
Are they taddr or zaddr privkeys?
Was rescanning enabled/disabled ?
As another data point, the coredump does not seem to happen every time. I was testing and was importing one valid privkey and usually a few invalid privkeys at a time. I only got this coredump one time in about 10 imports and all imports had rescanning disabled. All valid imports I was testing with were taddr privkeys.
If somebody hits this coredump and can provide a backtrace, please also add this data:
How many valid/invalid privkeys were being imported?
Are they taddr or zaddr privkeys?
Was rescanning enabled/disabled ?
UPDATE: I think I was incorrect, this bug only happens when rescan=true, because line src/mainwindow.cpp:1323 which is frame #1 in the backtrace only executes when rescan=true
UPDATE: I think I was incorrect, this bug only happens when rescan=true, because line `src/mainwindow.cpp:1323` which is frame #1 in the backtrace only executes when rescan=true
@onryo see if you can reproduce the coredump with the latest commit 3a6f632b9bc94b626be88964d3934b898fa6bb25 on dev branch.
In doing research on this I found https://forum.qt.io/topic/40088/qlineedit-settext-generating-segmentation-fault/5 and basically it seems like this kind of thing can happen when the QLineEdit object is accessed from another thread and it's already been deleted or not initialized.
I think you got this, I was able to restore from block 0 multiple times with z-addrs.
> @onryo see if you can reproduce the coredump with the latest commit 3a6f632b9bc94b626be88964d3934b898fa6bb25 on dev branch.
>
>
> In doing research on this I found https://forum.qt.io/topic/40088/qlineedit-settext-generating-segmentation-fault/5 and basically it seems like this kind of thing can happen when the QLineEdit object is accessed from another thread and it's already been deleted or not initialized.
I think you got this, I was able to restore from block 0 multiple times with z-addrs.
I was using a new Rescan feature with a specified block height, it triggered a "Segmentation fault", though yesterday I used the same feature/block height. For now just to not forget, I will debug later.
@onryo if it generated a coredump, a backtrace would be useful
For coredumps, run
ulimit -c unlimitedto make sure your shell will generate coredumps and then run the application which coredumps. In the Olden Times Linux would always make the "core" file in the same dir as the binary that makes it. But I have now seen that some new Linux distributions put them in weird places, for instance Arch puts them in /var/lib/systemd/coredumpOnce you have a coredump file (which is usually called "core" or "core.XYZ" where XYZ is the PID that generated it) you can then type
gdb binary_name core_filenameand then typebtto generate the backtrace. We should have this info written down somewhere in our dev docs because it comes up often.It actually seems the coredump can happen when you are not rescanning, any time you are importing privkeys. This coredump happened even though I disabled rescanning.
Here is a partial backtrace (all the rest of it is deep QT internals stuff)
It seems like the bug is in QT itself, maybe we can change our code to not trigger it. The above happened with QT 5.12.8
I wasn't able to reproduce the coredump yet. I am using 5.15.8, but I used the same Qt version in the past so it should trigger at some point.
On Debian 12 it is in the same directory as well.
Maybe something new for you:
As another data point, the coredump does not seem to happen every time. I was testing and was importing one valid privkey and usually a few invalid privkeys at a time. I only got this coredump one time in about 10 imports and all imports had rescanning disabled. All valid imports I was testing with were taddr privkeys.
If somebody hits this coredump and can provide a backtrace, please also add this data:
How many valid/invalid privkeys were being imported?
Are they taddr or zaddr privkeys?
Was rescanning enabled/disabled ?
UPDATE: I think I was incorrect, this bug only happens when rescan=true, because line
src/mainwindow.cpp:1323which is frame #1 in the backtrace only executes when rescan=true@onryo see if you can reproduce the coredump with the latest commit
3a6f632b9bon dev branch.In doing research on this I found https://forum.qt.io/topic/40088/qlineedit-settext-generating-segmentation-fault/5 and basically it seems like this kind of thing can happen when the QLineEdit object is accessed from another thread and it's already been deleted or not initialized.
I think you got this, I was able to restore from block 0 multiple times with z-addrs.
This bug was caused by a callback that tries to use a variable
pui.rescanfromfrom the import GUI after it is gone.