Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Create Manual Match" doesn't work #2215

Closed
cpast opened this issue Aug 19, 2020 · 9 comments
Closed

"Create Manual Match" doesn't work #2215

cpast opened this issue Aug 19, 2020 · 9 comments
Labels
Milestone

Comments

@cpast
Copy link

cpast commented Aug 19, 2020

I have two versions of an executable. There are two functions I know correspond, but that Ghidra didn't pick up on as corresponding. I'd like to manually tell it "these two are a match," but selecting the "Create Manual Match" item in the right-click menu has no effect. I can't even tell if there's a log with any issues.

@dragonmacher
Copy link
Collaborator

dragonmacher commented Aug 19, 2020

Is either match marked as 'blocked' in the UI? A blocked match will have a status/icon in the Matches table indicating as much (you may have to filter the table to see it if there are too many other matches). A match is considered blocked if it has already been linked somehow.

@cpast
Copy link
Author

cpast commented Aug 19, 2020

No. There are only a few blocked matches, and neither function is part of them.

@dragonmacher
Copy link
Collaborator

dragonmacher commented Aug 19, 2020

OK. Sounds like a bug then. I vaguely recall seeing a bug related to creating manual matches. We will have to investigate this.

Regarding the log, there is an application log in {user home}/.ghidra/.ghidra_/application.log. You can open that in a text editor to see if there are any related error messages or stack traces.

@cpast
Copy link
Author

cpast commented Aug 20, 2020

There are no related log messages of any kind.

@dragonmacher
Copy link
Collaborator

I did some digging into the action. The code is very straight-forward. Once the action is executed, it creates a match in the given session. To help us better understand the issue, can you explain from where and how you executed the action? (The action can be performed from multiple UI elements, each of which may have different validation logic.)

@cpast
Copy link
Author

cpast commented Aug 20, 2020

In the two Code Browser windows associated with the VT session (SOURCE and DESTINATION), I navigated to the functions in the listing. In both listings, the cursor was on the first instruction of the function. Then in the SOURCE window, I right-clicked, and selected "Version Tracking Match" -> "Create Manual Match". I also tried "Create and Accept" and "Create and Apply."

@dragonmacher
Copy link
Collaborator

I will test that case. You may have different results if you execute the command from the the Version Tracking Functions table. This can be found in the main Version Tracking window (accessible from the Window menu, if not already showing).

The functions window presents all functions from both programs. Selection the appropriate function in each of the split pane windows and then you can right-click and Create Manual Match. I am curious to see if 1) the action is enabled there and 2) if it works for you.

@dragonmacher
Copy link
Collaborator

I can reproduce the issue when running the action from the tool as you have done. Under the hood there is an exception indicating that a transaction has not been started. That exception is held on to by the task with the expectation that it will later be reported. However, there is currently no code that reports the errors in that case.

This is likely fallout from a refactoring. Further, there are clearly no tests written to handle this specific use case.

@cpast
Copy link
Author

cpast commented Aug 20, 2020

Interestingly, the functions view said "a match already exists" when I told it to create a manual match (I guess some flag started getting set when I created it from Code Browser?) However, it then proceeded to create the match properly. Thanks for the info; in the meantime, I can use this as a workaround.

astrelsky pushed a commit to astrelsky/ghidra that referenced this issue Sep 19, 2020
@ryanmkurtz ryanmkurtz added this to the 9.2 milestone Feb 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants