Skip to content
This repository has been archived by the owner on Feb 19, 2021. It is now read-only.

IDA Crashes when syncing structures #78

Open
ghost opened this issue Nov 16, 2018 · 13 comments
Open

IDA Crashes when syncing structures #78

ghost opened this issue Nov 16, 2018 · 13 comments

Comments

@ghost
Copy link

ghost commented Nov 16, 2018

2 uses are using IDArling to work on a database.

If user A creates or edits any structure (including renaming fields) then the IDA instance for user B will crash.

From turning the server logging level up to DEBUG it looks like the IDA instance crashes either during or after receiving the DefaultEvent packet that contains the full information of all the structures in user A's database.

Here is a redacted extract from the server log:

[DEBUG] (10.45.3.140:41910) Received packet: DefaultEvent(sname=struc_abc, event_type=struc_member_renamed, offset=0, newname=testing, type=event)
[DEBUG] (10.45.3.123:43426) Sending packet: DefaultEvent(sname=struc_abc, event_type=struc_member_renamed, offset=0, newname=testing, type=event)
[DEBUG] (10.45.3.140:41910) Received packet: DefaultEvent(local_types=[[1, '__n64', '\x1dQÑ\x1b\x02%\x1b\x03$\x1b\x05#\x1b\t"\x1b
<CUT>
[DEBUG] (10.45.3.123:43426) Sending packet: DefaultEvent(local_types=[[1, '__n64', '\x1dQÑ\x1b\x02%\x1b\x03$\x1b\x05#\x1b\t"\x1b
<CUT>

This issue appears to be 100% repeatable across all databases. We are using IDA 7.1 on Ubuntu with the standalone server.

@ghost
Copy link
Author

ghost commented Nov 16, 2018

Update: This only appears to happen one way when user A creates or edits structures in their database. If user B makes the change then this is correctly synced to user A's database and no crash occurs.

@patateqbool
Copy link
Member

Hi sday15,
Thanks for the bug report, I'll push a patch during the day, let me know if it's fix your problem please

@patateqbool
Copy link
Member

Hi @sday15,
I've tried to fix the bug, unfortunately LocalTypes and user-defined Struct/Enum conflict...
I'm still working on a solution for this issue.

@NyaMisty
Copy link
Contributor

NyaMisty commented Nov 19, 2018 via email

@patateqbool
Copy link
Member

Sorry, I'm not sure to understand the sentence correctly, but here is my answer:

When creating a struct/enum in struc/enum view, first a LocalTypesChanged event is sent, then a Struct/enum related event is sent. For the moment, my only idea is to "queue" the LocalTypesChanged event, wait for the next event, if the next event is a Struct/enum related event, drop the LocalTypesChanged event, else send LocalTypesChanged event then the next event.

@NyaMisty
Copy link
Contributor

NyaMisty commented Nov 20, 2018 via email

@patateqbool
Copy link
Member

Currently, we can't rely on our implementation of LocalTypes synchronization because we delete the structure each time a member is added in it. It's a problem because it breaks all the Structure Offset dependency used in the assembly view.

@NyaMisty
Copy link
Contributor

NyaMisty commented Nov 20, 2018 via email

@patateqbool
Copy link
Member

I agree, I'm going to push a fix that disables localTypes tonight until we have a stable fix to integrate them.

@ghost
Copy link
Author

ghost commented Nov 26, 2018

disabling localTypes appears to have fixed the crashing issue.

@patateqbool
Copy link
Member

Good to know, I am always looking for a solution to properly integrate localTypes.
Thanks for the feedback :)

@ghost
Copy link
Author

ghost commented Nov 26, 2018

It looks like applying structures to a memory address in the "IDA View", using Alt-Q does not appear to be synced properly between users anymore. Structures that were created before this change do sync, but any that were created after the change (even though they sync correctly) don't get applied.

@patateqbool
Copy link
Member

I guess this manipulation calls LocalTypesChangedEvent, which is now commented due to the previous bug.
I confirm the hypothesis tonight and try to find a solution in the coming days.
Thanks for the report @sday15

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants