Print

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

[RedDwarfStepper]

Assuming the program blows up in the EA thread (do we know it's there, rather than the thread being at that location when things blow up elsewhere?) it looks like the data received is somehow corrupt, which is uncomfortable as it's provided by DF rather than our code (I'd rather get egg on my face from screwing up than being able to say it wasn't my fault when the former means I can actually fix it, but the latter doesn't).

Thinking about it again, we really can't be sure that this is exactly what blows up. We only know for sure that EA is at least one part of the problem: If our user starts a search with EA it crashes. But that does not mean that no other plugin is contributing to this crash. It could very well be a combined effort of two or more actors...
So to make sure about that I have one more test for Deuslinks: remove all other plugins and try to provoke the crash.
Since that is a quite tedious test I'd like him to test something else before that. Another hunch...

@Deuslinks:
Could you please start a new session like always, best with a big world, load EA if not already done and manually move the cursor to the top left corner of the region view and only then open the view for the search criteria via 'f', change the criteria and then 'f' again?
Does it still crash right away? If so could you please upload the resulting DMP-file?
If is crashes but at the end of the search - so after some time instead of right away - please upload the resulting DMP-files and have a try with dll uploaded here.
How does that one behave? If it crashes as well:
We (read: you) need to temporarily "deactivate" all other plugins that might interfere - this is more involved than the other tests, if you feel up to it you should have some time at your hands and best create a copy of your LNP/PeridexisErrant's Starter Pack so you don't destroy your regular setup.
Okay, here we go:
- Please move all plugin-dlls with the exception of embark-assistant.plug.dll from the plugins folder to a separate folder, e.g. "deactivated_plugins" or just create a copy of the "Dwarf Fortress 0.47.05\hack\plugins\" folder, rename the copy to "deactivated_plugins" and then remove the dlls from the original folder
- The only remaining dll-file in the plugins folder should be the "embark-assistant.plug.dll" with a size of around 653 KB, that you downloaded from here.
Do what you do and never mind the warning about the missing plugins... Crash? => Please upload the dump and don't mind my sobbing

[lethosor]

- Would more crash dumps with the debug-dlls help? Perhaps we're missing something?

In general, I would say yes. You currently have a crash dump with several active threads, and it can be difficult to know where the crash actually originated sometimes, despite what the dump might say. It's likely that the crash occurred in the embark-assistant thread, given that using embark-assistant triggers the crash, but it would be easier to rule out unrelated threads with a handful of other crash dumps (say, 5 maybe).

Your advice about disabling other plugins is also a good idea.

PPS:
One more thing I just found: The current pressed key is CURSOR_UPLEFT_FAST, coming from here
https://github.com/DFHack/dfhack/blob/1c32783dd2628f22c5355b84e49e5c7357b52cb8/plugins/embark-assistant/matcher.cpp#L2966
or to be exact here
https://github.com/DFHack/dfhack/blob/1c32783dd2628f22c5355b84e49e5c7357b52cb8/plugins/embark-assistant/matcher.cpp#L2967
so the end of a loop - hm.

One possible important thing to check would be to ensure that the core is suspended when matcher.cpp calls feed_key() - this is writing data that DF reads from, so if DF is accessing that data at the same time, there could be a possible race condition there. I'm not sure why that would result in a crash when reading from a std::set, though - that should be local to the calling thread.

Edit: per "Core::getInstance().isSuspended()" it does appear to be suspended here, which is good.

Edit: one more thing: the getHotkeyCmd() thread is normal and expected to be idle in that function. It typically acts only on DFHack-managed hotkeys (registered with the "keybinding" command). feed_key() probably can't trigger this thread.

[PatrikLundell]

Thanks for chiming in lethosor, I think we need all the help we can get.

I agree disabling as much unrelated functionality as possible is a good approach, and testing to see what happens if we start in the top left corner is good as well (if it doesn't crash, repeat a couple of times to ensure it's not one of the fluke successful runs).

When I put a breakpoint at the indicated location in EA on my machine, I did get one call that was initiated by embark-tools (I think the key issued was A102, but I may be misremembering). As far as I could tell that happened after the first feature shell had been processed, which is the time at which the UI replaced the find profile overlay with the search result one (which also displays the native DF UI "underneath", and thus the embark-tools additional UI as well). However, this happens after the point we believe we see the crash happening at.

[Deuslinks]

Hi there I will give it a shot tonight and report the results for you.

[lethosor]

I did get one call that was initiated by embark-tools (I think the key issued was A102, but I may be misremembering)

For what it's worth, this is normal when other plugins are enabled and hook into the same screen - they'll end up calling each others' hooks, and unless they specify a priority, there's not a fixed order to these calls across DF runs (although they should usually occur in the same order in a single DF session, unless plugins are loaded/unloaded).

[snowyscales]

so i noticed these bright red abreviations that sometimes show below the sand/clay/soil list. and i can figure the "Re" mean Reanimating and the "Th" means Thralling. but what does the "TS" mean and what other abbreviations(and their meanings) can be shown in that section?

[lethosor]

There's a description of them in the embark-assistant help in-game - looks like on the screen titled "Embark Assistant Help/Info General Page".

Evil weather, when present: BR = Blood Rain, TS = Temporary Syndrome
PS = Permanent Syndrome, Re = Reanimating, and Th = Thralling. Incursions.

[A_Curious_Cat]

Any chance that this will be updated for 50.X?

[PatrikLundell]

I will investigate if I'm able to do so only when DF becomes playable, i.e. keyboard support is returned. That doesn't stop mouse tolerant people to take up the task earlier, as this is part of DFHack.

I can mention two things here:
- The biome determination logic was changed prior to the Premium release, so some biome determinations were incorrect. The underlying logic could use an update, although it's no longer part of this plugin itself. The differences were not huge, but present.
- I've noticed that mousing around pre embark causes mid level tiles to get loaded, so once you can order the cursor to move with keyboard input again you should be able to load all of this info into memory before performing any processing, thus removing issues with having to cache information and processing the data in two passes. It can be noted that the information is loaded unordered, but that can be handled e.g. with an intermediate coordinate translation matrix.