Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Nilsolm]

I managed to find out a bit more in the meantime, actually. Something to do with writing the config. Here is the backtrace:

Code: [Select]

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff673c859 in __GI_abort () at abort.c:79
#2  0x00007ffff6d0e951 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff6d1a47c in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff6d1a4e7 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff6d1a799 in  () at /lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007ffff797bd1e in DFHack::PersistentDataItem::ival(int)
    (this=this@entry=0x7ffff09ccad0 <config_kloker>, i=i@entry=7) at ../library/modules/Persistence.cpp:107
#7  0x00007ffff098f529 in save_kloker_config() () at ../plugins/manipulator.cpp:853
#8  0x00007ffff098f9d5 in read_kloker_config() () at ../plugins/manipulator.cpp:861
#9  0x00007ffff09a04b8 in viewscreen_unitklokerst::viewscreen_unitklokerst(std::vector<df::unit*, std::allocator<df::unit*> >&, int) (this=0x7fffa7d99280, src=..., cursor_pos=<optimized out>) at ../plugins/manipulator.cpp:4121
#10 0x00007ffff09a076f in dts::make_unique<viewscreen_unitklokerst, std::vector<df::unit*, std::allocator<df::unit*> >&, int&>(std::vector<df::unit*, std::allocator<df::unit*> >&, int&) () at ../library/include/MiscUtils.h:76
#11 0x00007ffff09b5027 in unitlist_hook::interpose_fn_feed(std::set<df::enums::interface_key::interface_key, std::less<df::enums::interface_key::interface_key>, std::allocator<df::enums::interface_key::interface_key> >*)
    (this=<optimized out>, input=<optimized out>) at ../plugins/manipulator.cpp:6469
#12 0x00007ffff6eb6234 in interfacest::loop() () at /home/xxx/Games/dev/df_linux/libs/libgraphics.so
#13 0x0000000000a486ee in mainloop() ()
#14 0x00007ffff6e9a1c5 in enablerst::async_loop() () at /home/xxx/Games/dev/df_linux/libs/libgraphics.so
#15 0x00007ffff6e9a4e0 in call_loop(void*) () at /home/xxx/Games/dev/df_linux/libs/libgraphics.so
#16 0x00007ffff74aaf3c in  () at /lib/x86_64-linux-gnu/libSDL-1.2.so.0
#17 0x00007ffff74eabaf in  () at /lib/x86_64-linux-gnu/libSDL-1.2.so.0
#18 0x00007ffff667d609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#19 0x00007ffff6839153 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

[strainer]

Thanks Nilsolm, that's not a terribly complicated bit of kloker so it looks like dfhacks World::PersistentDataItem is just bugged on the 47 beta. Kloker uses it in two functions

Code: [Select]

save_kloker_config :837 and

Code: [Select]

read_kloker_config :856 just to stash values which set the color theme and detail levels and things. Other plugins were using it too so maybe it should be fixed or maybe it has been depreciated for a better method.
You might like to just disable config reading and saving in the meanwhile by commenting out parts of those functions but it will be a bit of a puzzle, as the values are "magic cookies"...

This could work:

Code: [Select]

line 837...
void save_kloker_config()
{
    /*
    config_kloker = World::GetPersistentData("kloker/config");
    if (!config_kloker.isValid()) {
        config_kloker = World::AddPersistentData("kloker/config");
        if (!config_kloker.isValid())
            return;
    }

    config_kloker.ival(0) = color_mode + 1;
    config_kloker.ival(1) = hint_power;
    config_kloker.ival(2) = spare_skill;
    config_kloker.ival(3) = show_details + 1;
    config_kloker.ival(4) = tran_names;
    config_kloker.ival(5) = theme_color;
    config_kloker.ival(6) = show_curse;
    config_kloker.ival(7) = happy_label_seed;
    */
}

void read_kloker_config()
{
    /*config_kloker = World::GetPersistentData("kloker/config");

    if (!config_kloker.isValid()) {
        save_kloker_config();
        return;
    }*/
    color_mode = -1; // config_kloker.ival(0) - 1;
   
    if (color_mode == -1) { color_mode = 1; hint_power = 1; }
   
    //hint_power = config_kloker.ival(1);
    spare_skill = 0;// config_kloker.ival(2);
   
    show_details = 1; //config_kloker.ival(3) - 1;
   
    if (show_details == -1){ show_details = 1; }
   
    tran_names  = 0;//config_kloker.ival(4);
    theme_color = 0;//config_kloker.ival(5);
    show_curse  = 1;//config_kloker.ival(6);
    happy_label_seed = 0;//config_kloker.ival(7);
   
    if (theme_color == 0){ cltheme = cltheme_a; }
    if (theme_color == 1){ cltheme = cltheme_b; }
    if (theme_color == 2){ cltheme = cltheme_c; }
}


[lethosor]

Code: [Select]

    config_kloker.ival(7) = happy_label_seed;


This appears to be the problem - ival() only supports 7 integers, i.e. from 0 to 6. This is mentioned here - admittedly that's not relevant for C++ developers, but it was the first mention I found. The persistent storage system was rewritten over the summer, so that's probably why it's crashing now, but I think it would have crashed in 0.44.12-r3 too, which had the new system. Even if it didn't crash with the old system (pre-0.44.12-r3), it wouldn't have worked, because the old system stored ival()s in language_name words, which is only a 7-element array anyway.

Some possibilities I've thought of (could be more):
- shove multiple pieces of data into one integer (I'm guessing show_curse might just be 1 bit from its name, which could make it a candidate)
- store something into one of the string values instead
- store your config in a JSON file instead (admittedly a harder change)

[strainer]

Thanks Lethosor ! That pesky "happy label seed" is kind of an easter egg which just allows the happy/stress label to mysteriously change occasionally in the history of the fort, if its never set by the player. So it could just be zeroed, or maybe this ...

Code: [Select]

line 852 ~
       config_kloker.ival(6) = happy_label_seed*2 + (show_curse & 1);


Code: [Select]

line 878 ~
      happy_label_seed = config_kloker.ival(6) / 2 ;
     show_curse = config_kloker.ival(6) & 1 ;


[Nilsolm]

Thanks Lethosor ! That pesky "happy label seed" is kind of an easter egg which just allows the happy/stress label to mysteriously change occasionally in the history of the fort, if its never set by the player. So it could just be zeroed, or maybe this ...

Code: [Select]

line 852 ~
       config_kloker.ival(6) = happy_label_seed*2 + (show_curse & 1);


Code: [Select]

line 878 ~
      happy_label_seed = config_kloker.ival(6) / 2 ;
     show_curse = config_kloker.ival(6) & 1 ;


That appears to solve the problem. No more crashes and everything seems to work. I can create a PR with the changes I've made later if you want.

In the meantime, here is a build for Linux, compiled for the latest DFHack. I could try making one for Windows as well later, but last time I tried, I couldn't get DFHack to compile.

[strainer]

 Alright  Thanks Nilsolm

A git PR would ideal for the updates you figured out. I have a win compiling setup on my laptop but it takes some focus to spin up and I'm a bit distracted at the moment working outdoors for my grudges...

[Nilsolm]

Unfortunately, I've encountered more issues that need fixing. I did a bit of testing with a pre-existing save instead of a newly created one, and I'm seeing a lot of crashes while cycling through the unit list. At a first glance, they seem to be related to the relationship type changes in 47.XX.

I'll look into it later today and report back once I've found out more.

[strainer]

Ah, that code in 'setDescriptions' is not bestest structured .  If you like post the crash log I may be able to spot what to change or disable to make it safe. I spotted what I expect must be a typo at line:2411 - a wrong "current_soul" pointer check is just disabling something that may not be working either. There are lots of redundant checks in the method currently as it just returns near the beginning if there is no "current_soul" (zombies and things).

[Nilsolm]

The culprit turned out to have been line 2272. Probably something related to changed made in this commit. The renaming of links to hf_visual was already accounted for, so it must be some other reason. Removing that line stops the crashes. It doesn't appear to serve any purpose in the code from what I can tell, so it shouldn't lead to loss of functionality. Indeed, I haven't noticed any.

And I am not sure about the other possible issues you mentioned, but I'll do some more testing in the coming days to see if I find some more bugs.

[strainer]

this line :

Code: [Select]

line 2272/3:    rels = (figure->info->relationships->list).size();
was just storing the size of the list as 'rels' to loop through in the next loop, but I forgot to use 'rels' and just used '(figure->info->relationships->list).size()' again.

That loop tallies the number of characters which the unit feels are friends, aquaintances, and theoretically "bullies" and "heroes" but I never seen those. The relations are indicated in the brown description text, eg.  Frd0:4  ,means 0 friends, 4 aquaintances. I think its a useful detail, once the player notices it and figures out what it means.

So its curious that just removing line 2272 stops crashes, since the loop with the offending pointer should still run sometime. The loop should run when " if (figure->info->relationships) " is true, but should crash now when it does run, so relationships doesn't seem to be at 'figure->info->' anymore. hmmm

[Nilsolm]

I noticed as well that size() is called again in the loop, but for some reason, it doesn't cause a segfault. I don't really know why, but then again, my C++ is rusty, to put it nicely.

Relationships are still where they used to be I believe, but relationship types seem to have changed. Some new ones were introduced in 47.01. The relationship counter in the game is working, more or less; it doesn't appear to properly count the number of friends. I have a dwarf with 44 acquaintances, 2 friends and 2 close friends, but the Kloker screen displays Frd0:48.  So that part of the code needs to be fiddled with a bit more.

[strainer]

hmmm, I think you might still be on the old xml where 'hf_visual' is still 'list'. Then the 'rels =...' could crash on units which have a historical figure id but dont have 'info->relationships'. The relationship-attitude tally loop only runs after a check that 'info->relationships' exist. Its a minor feature anyway.

[lethosor]

hmmm, I think you might still be on the old xml where 'hf_visual' is still 'list'. Then the 'rels =...' could crash on units which have a historical figure id but dont have 'info->relationships'. The relationship-attitude tally loop only runs after a check that 'info->relationships' exist. Its a minor feature anyway.

If an XML field got renamed, then the plugin simply wouldn't compile at all - the only way I could think of that a crash could occur is if two fields' names got swapped, and a field that the plugin thinks is never null is now null sometimes. (Of course, I may be misunderstanding; if you think an XML change broke things, I could try to give better advice if you have a link to that change.)

[strainer]

Sorry, my confusion - Nilsolm mentioned he'd already changed `list` to `hf_visual`
The line `rels = (figure->info->relationships->hf_visual).size();` was likely crashing because it was before the check that `figure->info->relationships` exists. The loop that reads `figure->info->relationships->hf_visual` is after a check.

[LordBalkan]

Definitely - I feel its feature complete now so updating should not be a big problem. Im away from my linux machine so can only do windows compiles at the moment. Which version are you needing the 44.12. r3 ? or the latest 47 beta? If we could get dfhack to pull kloker then it will just be available with dfhack. That would be ideal.

Nice! Was also away from internet for a couple days, but I'm kindly asking for a Kloker update to 47.XX version.
Since ToadOne said that 47.04 was the last and definitive release before Premium Steam Version, I guess that there will be no major changes until the great release.
I'm not much of a developer myself so I don't know if those last posts were about it.

But thankyou again in advance for this amazing mod