guayadeque-0.6.2 crashes on Fedora 41 with new version of wxsqlite3-4.10.0 #34
Comments
Unfortunately, I don't have access to a Fedora 41 system. Nevertheless, I'd like to know which wxWidgets version you use on this system. And which compiler. wxSQLite3 is tested on a Ubuntu platform. I have not experienced such crashes there.
The gdb stack trace shows that the crash happens in the very first initialization function of SQLite3MultipleCiphers. AFAICT there doesn't happen anything that is in any way related to the changes introduced in the new version of the underlying SQLite3MultipleCiphers code. A global structure gets initialized with empty entries (in the very same way as in prior versions). No cipher specific code is executed. I really have no idea what may cause an Illegal instruction exception under these circumstances. |
wxGTK-3.2.6-1.fc41.x86_64 $ gcc --version |
Thanks for the information. I'll try to look into the issue. This will take some time, because I have to set up a Fedora environment first. |
|
I managed to set up a VM with Fedora 41. I compiled wxSQLite3 4.10.0 using the gcc and wxWidgets version you mentioned. The samples coming with wxSQLite3 work without any issues. I did the same test under Ubuntu 24.04.1 and Linux Mint 22. On all 3 platforms I was not able to reproduce the crashes you observed. I have not yet tested with guayadeque. Could you please test the samples coming with wxSQLite3 on your system, and report back whether you experience crashes with them or not? |
|
can you describe in detail what I should do in the samples directory of wxsqlite3-4.10.0 ? |
Assuming you have a clean local copy of the wxSQLite3 GitHub repository, you simply build the library with the following commands (this includes building the samples), and then run the samples: minimal sample (command line), treeview (GUI). As said I did not experience any crashes during this build and test process, but that may be different on your system. |
|
same problem as with guayadeque. (fresh wxsqlite3 source no precompiled version installed) minimal an treeview crashes I am perplexed :-( |
|
In the meantime I built guayadeque in my Fedora 41 VM. The application did not crash on starting. That makes it difficult to analyze the cause of problems on your system. I believe that there is a problem, because another user reported a similar problem, but without being able to reproduce the problem, it is really difficult to track down the cause of the crash. |
That is, both crash immediately on starting the application?
Me too. Nevertheless, the situation is now far better, because we have a much less complex application for tracking down the problem. However, I need your assistance, because I don't experience the problem in my development environment. The first step would be the following test: That is, excluding the new cipher scheme AEGIS. My hope and expectation is that the minimal sample does not crash then. TIA for your assistance. |
|
w/o aegis it runs, see attachement. the current wxsqlite3-4.10.0 Fedora rpm package was built with the following config options: |
That's good news. Thanks. So, let's do the next step. This involves editing the amalgamation. After line 283230 you find the following code section: #if defined(_MSC_VER)
# pragma section(".CRT$XCU", read)
static void __cdecl _do_aegis_init(void);
__declspec(allocate(".CRT$XCU")) void (*aegis_init_constructor)(void) = _do_aegis_init;
#else
static void _do_aegis_init(void) __attribute__((constructor));
#endif
static void
_do_aegis_init(void)
{
(void) aegis_init();
}Please disable this section: #if 0 /* Exclude AEGIS initialization */
#if defined(_MSC_VER)
# pragma section(".CRT$XCU", read)
static void __cdecl _do_aegis_init(void);
__declspec(allocate(".CRT$XCU")) void (*aegis_init_constructor)(void) = _do_aegis_init;
#else
static void _do_aegis_init(void) __attribute__((constructor));
#endif
static void
_do_aegis_init(void)
{
(void) aegis_init();
}
#endif /* AEGIS initialization */This code section is the only one that gets executed before anything else happens. This is code from the original AEGIS implementation. Being lazy I kept it, but initialization could be handled in a different way. I don't know whether this code is actually the cause of the crash, but we will hopefully know after the next test. Now build wxSQLite3 again (without excluding AEGIS this time), and run the minimal sample. Crash or no crash - that's the question. 😓 |
|
now I've patched the file src/sqlite3mc_amalgamation.c and build it w/o aegis configure --without-aegis the new test is running fine, see minimal2.txt |
Ah, sorry, I didn't make myself clear enough. The previous test showed that the presence of the AEGIS code was enough to trigger the crash. The patch has only an effect, if the AEGIS code is included again. Please run the test again, but now WITHOUT the option If that doesn't crash, we will know that the crash is either caused by the code excluded by the patch (or by the code executed in function Thank you very much that you are helping in tracking down the problem. |
|
program minimal (aegis enabled) dumps now with: |
I'm at a loss. I have no idea why just the presence of the AEGIS code can cause a crash in the initialization function.
The crash happens at the same place as before, when the Can you determine the value of |
|
I really have no idea how to debug this |
Yes, debugging can be tricky sometimes. Sometimes I add debug output to the code (using
Hm, that sounds like the modified source code was not compiled into the executable you are debugging. Please double check that you are debugging the correct version.
I guess this means that the application crashes directly for the first iteration step (with
The value
Regarding static const CipherDescriptor mcSentinelDescriptor =
{
"", NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL
};
static const CipherDescriptor mcDummyDescriptor =
{
"@dummy@", NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL
};There are 8 static const CipherDescriptor mcSentinelDescriptor =
{
"", NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL
};
static const CipherDescriptor mcDummyDescriptor =
{
"@dummy@", NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL
};It shouldn't make a difference, because typically the compiler should add null values for the missing items automatically, but it's certainly better to specify all values explicitly (although the code obviously worked in prior versions without issues). I don't know whether the missing values could cause a crash, but maybe it's worth a try to correct those lines. Another option to code this initialization would be to use |
|
I found another possible cause for the error: The original AEGIS code uses various However, for SQLite3 Multiple Ciphers the AEGIS code is amalgamated into a single compilation unit. That is, the last occurence of a I don't know whether this is really the cause of the crash, but to be on the safe side I will go through the code and add |
|
hope you will find a solution for this issue. |
Me too. I will make the modifications mentioned in previous posts today. I'll let you know when they are available for further testing, because I still need your assistance to test whether the modifications solve the problem or not.
My pleasure. I'm grateful that you reported the issue and that you help to track down the cause and to test modifications. |
|
I compiled wxsqlite3-4.10.0 with your patch Is this the final version of wxsqlite3, or create a new tag version of 4.10.1 ? |
That's great news! 🎉 Thank you so much for testing and confirming that these patches solve the problem. I'm really relieved!
No, I will make a new release, of course. Later today, or tomorrow.
Great. |
|
I just prepared the release of wxSQLite3 4.10.1. |
|
new wxsqlite3-4.10.1 rpm packages have been created for Fedora, the problem has been solved. Nochmals Danke für Unterstützung Ulli. |
Hi,
I have compiled and installed wxsqlite3-4.10.0 for Fedora 41. I have also recompiled and installed guayadeque-0.6.2.
Now guayadeque crashes and a guayadeque.xml with the following content is created.
gdb backtrace:
Regards
Martin
The text was updated successfully, but these errors were encountered: