FindCodeLocation does not find source code panel even if its open

[tonsa1]

I added a pull request to fix this https://github.com/EpicGames/raddebugger/pull/87.

https://github.com/EpicGames/raddebugger/assets/13787455/4aea3498-24ad-4e94-8648-8f53b55f24f6

This results in that a new panel is created for the same source code every time FindCodeLocation is called. Also the breakpoint does not get rendered in the new panels but I think thats just an outcome of the same issue.

I took a look at it in a debugger and I found out why the issue happens and tracked the source issue. In the first loop where it tries to find the panel/view pair that could have src file, the only combination where both have the same source file is this:

In the if statement it checks for: viewed_entity == src_code and even though they have the same source code the Entities are not the same so it fails and it thinks that there is no source file currently open so it creates a new one.

In the start of the function it tries to get the src_code with src_code = df_entity_from_path(params.file_path, DF_EntityFromPathFlag_All); but this returns the wrong entity even though the file path is correct

Taking a look at df_entity_from_path we can see that the file_no_override is the correct one but the function returns the file_overrides_applied

I checked the override pass and the I noticed something that I would assume is not correct.

The override check keeps going through a lot of strings that are all the same path.

The same string repeats starting from 0x27F2975FA40 and ending at 0x27F297B5C40

I found that df_possible_overrides_from_entity(Arena *arena, DF_Entity *entity) is the one creating the strings and I tracked the problem to line 2225 in df_core.c DF_Entity *override = link_overridden_sibling; There is no check if the override is nil and if its never set then the source is DF_Entity *link_overridden_sibling = &df_g_nil_entity; thus it is not valid. Because the override is not valid there is no next, so new names are getting allocated every frame it seems.

[ryanfleury]

I think the source of the bug here is however you created a blank file path map. The frontend should be deleting that row if both sides are blank. How exactly did you construct that?

[tonsa1]

I have absolutely no idea. I feel like I had those two lines there since the beginning. I tried to get rid of the second one and for awhile it didn't want to go away. Once I got rid of it somehow I don't seem to be able to get it back anymore. I have no idea where it came from or how. This is how its supposed to be right?

Even though I dont have the blank file path map anymore this issue still remains without it.

[ryanfleury]

Yeah that is how it should look by default.

Can you do me a favor and paste the full paths (right click + copy full path) of the two tabs that are opened?

[tonsa1]

Okay never mind. I tried to reproduce it again and somehow it seemed to be have gone away. So the file path map definitely has something to do with it. I tried fiddling around with the path again and I was able to get the second empty path there. Though I do not understand why I was able to reproduce the bug when I got rid of the empty file path map.

heres the paths if it even matters anymore C:/geimus/Game/OwnProjects/Asteroids/code/win32_asteroids.cpp C:/geimus/Game/OwnProjects/Asteroids/code/win32_asteroids.cpp

[tonsa1]

It seems that the issue only goes away after rebooting even if I remove the empty file path map. I will try to find a way to get the empty path somewhat reliably,

[ryanfleury]

Awesome, thanks. Yeah it's not entirely clear to me, but I will check out your PR when I get to this issue. File path maps are implicitly created when you do something like e.g. "Find Alternative", if you are missing source code. So that might be how you created it initially. Other than an unexpected interaction with that, I am not sure how it would be created...

[tonsa1]

Heres how to reproduce it:

https://github.com/EpicGames/raddebugger/assets/13787455/4d25b119-6a36-4f89-b677-f641826c021b

1. Add some paths in the same places as in the video
2. Exit the application normally
3. Reopen it
4. double click the second path to highlight it (dont delete it normally)
5. Click somewhere else and it should disappear like in the video

After this I can just delete the other path normally my pressing delete and it all the blank paths stay here

[ryanfleury]

Ahhhh okay yep, that is a bug in the UI then. I'll begin by fixing that.

[tonsa1]

https://github.com/EpicGames/raddebugger/assets/13787455/79621371-0044-4eee-b7cb-bedf19947c71

You can get rid of the issue by filling all of them and then removing normally

[tonsa1]

I believe I found the reason why this issue is happening. Normally the map_link->kind is DF_EntityKind_Nil when the Destination Path is empty. When you reopen the application the empty path is not DF_EntityKind_Nil anymore. Instead it is DF_EntityKind_Root and this seems to be the cause of the issue.

When the application starts and runs df_core_begin_frame it will set the link_dst_entity at line 7587 and the df_entity_from_path function returns the root entity. the dst_path given to df_entity_from_path is empty so I believe the result should be nil. But the df_entity_from_path function will always return the root entity because at line 2064 DF_Entity *parent = df_entity_root(); is set and this will be returned if it is not overwritten by anything else. Adding a check for the path size can fix this and df_entity_from_path can now return nil entities if the path is empty.

I added this check to the commit and you can see it in the MR.

[GloriousPtr]

Same for the command "open". New view is opened everytime even if a view with same file is opened already!

[ryanfleury]

This behavior should be resolved, but let me know if you run into it again, or if you notice any more behavior which incorrectly led to that "blank path map" situation.