#533 Crash at BackEnd::init_lists (sword_main.cc:185)

[Ildar Mulyukov]

no .xiphos/.sword folders.
Start in gdb.
(gdb) bt

0 0x00000000004a4f73 in BackEnd::init_lists (this=0x789e30,

mods=0x7247c0 <mods>) at ../src/backend/sword_main.cc:185

1 0x00000000004cd113 in main_init_lists () at ../src/main/lists.cc:125

2 0x00000000004e094e in settings_init (argc=1, argv=0x7fffffffe2d8,

new_configs=0, new_bookmarks=0) at ../src/main/settings.c:169

3 0x00000000004cd96a in main (argc=1, argv=0x7fffffffe2d8)

at ../src/main/main.c:234

Note: for (it = main_mgr->Modules.begin(); it != main_mgr->Modules.end(); ++it) looks suspicious. Should it be it++ ?

[Karl Kleinpaste]

Xiphos version? Platform?

I don't follow what's happened here at all. The code is simply picking up the set of modules already known in your .sword. It can have trouble there only if it was actually unable to create .sword, in which case Xiphos would have given up entirely long before it reached this point.

++it looks suspicious. Should it be it++ ?

No. Standard usage in C++, to avoid unnecessary potential creation of unneeded reference caused by ++ as a "post" (instead of "pre") operator that would simply then be destroyed.

I'd like to know what's going on here, but I have no clear idea about what to pursue. My own straightforward test of beginning with no .xiphos and no .sword caused no problem; Xiphos simply invoked mod.mgr as expected, upon finding no installed Bible modules.

[Ildar Mulyukov]

That's of course 4.0.3
System is x86_64 ALTLinux Sisyphus. I know it's not a very wide-spread distribution but I try to build Xiphos for it.
I can run it under the gdb. Could you give me a few recomendations on what to watch during the session?
Thanks!

[Karl Kleinpaste]

Just knowing what content was found in init_list's loops would be good. There has to be a reason why it got inside a loop that is otherwise avoided based on Modules.end() and found a way to crash on something that isn't actually there.

[Ildar Mulyukov]

may this help?

(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/bin/xiphos-gtk3 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, BackEnd::init_lists (this=0x770df0, mods=0x7247c0 <mods>)
    at ../src/backend/sword_main.cc:182
182     for (it = main_mgr->Modules.begin();
(gdb) next
183          it != main_mgr->Modules.end();
(gdb) 
182     for (it = main_mgr->Modules.begin();
(gdb) 
185         SWModule *m = it->second;
(gdb) 

Program received signal SIGSEGV, Segmentation fault.
0x00000000004a5211 in BackEnd::init_lists (this=0x770df0, mods=0x7247c0 <mods>)
    at ../src/backend/sword_main.cc:185
185         SWModule *m = it->second;
(gdb) print it
$2 = <error reading variable: Cannot access memory at address 0x614b0069666b0061>

[Karl Kleinpaste]

that makes no sense at all.

begin looking at module list. it's a std::map, keyed from name to pointer to the module structure.

iterator is not the end() of the list (i.e. list is not empty), so proceed within the loop. try to access the 1st element's module structure. fail. duh?

if there's nothing there, it should have matched on end() and left. if there's something there, then "it" must be reference-able to access it->second.

mystieries, just ongoing mysteries. i have never seen this, and i don't know how anyone can get it to fail in this way.

[Karl Kleinpaste]

closed here in sourceforge as we complete our move to github.
see https://github.com/crosswire/xiphos/issues.
use the Labels pulldown there to distinguish between bugs and enhancements ("feature requests").