Closed Bug 865142 Opened 9 years ago Closed 8 years ago

8 digit hex addresses within Java signatures not replaced by <addr> when ended with colon or replaced by <addr>: when ended with space

Categories

(Socorro :: Backend, task)

All
Android
task
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: scoobidiver, Assigned: lars)

References

Details

The @12345678: address is not replaced by <addr>:
See bp-968ff67c-9797-4515-ab54-3fc642130416.

The @12345678 address is replaced by <addr>: instead of <addr>
See bp-18c74ce4-1f97-4a60-8936-7e58f2130424.
This actually now is on the code of bug 863998, not the old code implemented in bug 726385.
Blocks: 863998
Blocks: 726685, 756737, 759301
there are some ambiguity and inconsistencies in the placement of ':' within java signatures.  Before I fix it, I want to make sure I'm not going to disrupt ongoing signature tracking.  

Java signatures are supposed to be in the form  "class: description: java_method"  or if that is too long: "class: java_method".  The colon is used to delimit the three (or two) sections. 

The code made the erroneous assumption that addresses of the form @01234567 would always be at the end of the description section.  The delimiting colon was added by the code that replaced addresses with "<addr>".  This meant that cases where there was no address, the colon would be missing as a delimiter between the description and the java_method.  In the case where the hex address was in the middle of the description, an inappropriate colon would exist after the address and there would be no colon between the description and the java_method.

in the two cases listed in comment 0, the signtures are now generated as:

bp-968ff67c-9797-4515-ab54-3fc642130416
    '''java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoNetworkManager@<addr>: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java)'''

bp-18c74ce4-1f97-4a60-8936-7e58f2130424
    '''android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@<addr> is not valid; is your activity running?: at android.view.ViewRoot.setView(ViewRoot.java)'''

any signatures of the form '''class: description-with-no-address at java_method''' will now be in the form '''class: description-with-no-address: at java_method'''

Please confirm that this is the correct algorithm.  If you rather see it in code: https://github.com/twobraids/socorro/blob/javasig-fix/socorro/processor/signature_utilities.py#L381
Assignee: nobody → lars
Target Milestone: --- → 49
This bug is not about the placement of : in Java signatures. It's about replacing any strings of eight figures by <addr> whatever there's at the end of the string.
noted. The corrective colon behavior is reverted leaving the corrective <addr> behavior intact.  

https://github.com/mozilla/socorro/pull/1261
Can you provide the result of this algorithm for the two crash reports?
both of those crashes are now in the unit tests:  

bp-968ff67c-9797-4515-ab54-3fc642130416:
java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoNetworkManager@<addr>: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java)

bp-18c74ce4-1f97-4a60-8936-7e58f2130424:
android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@<addr> is not valid; is your activity running? at android.view.ViewRoot.setView(ViewRoot.java)
Commit pushed to master at https://github.com/mozilla/socorro

https://github.com/mozilla/socorro/commit/bfa1aff21ac0ad51fb8c08a18096c9b75b1cc06b
Merge pull request #1261 from twobraids/java-addr-fix

fixes Bug 865142 - all hex addresses to be replaced with <addr>
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Thank you lars (comment 6 - bumping to QA verified. <3 Unit tests
Status: RESOLVED → VERIFIED
A colon is added for this signature and shouldn't: bp-546ebc06-ba5a-4400-9c9b-e4ec92130613.
After comment #3, changes to colon placement were reverted.  The first example in comment #6 demonstrates the colon placement behavior observed as incorrect in comment #9.   I took one week of silence after comment #6 to be assent that the examples given were correct.  In light of comment #3, please file a separate bug regarding the placement of colons.  Please include the precise rule for how colons should be placed within a java signature as we are in a state of ambiguity now.

from comment #6:

java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoNetworkManager@<addr>: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java)

from comment #9:

java.lang.IllegalArgumentException: Receiver not registered: org.mozilla.gecko.GeckoConnectivityReceiver@<addr>: at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java)
(In reply to Scoobidiver from comment #0)
> The @12345678: address is not replaced by <addr>:
> See bp-968ff67c-9797-4515-ab54-3fc642130416.
My bad! In that one, I was focused on the missing <addr> and haven't checked with the stack trace that the colon shouldn't have been there.

Let's live with that.
You need to log in before you can comment on or make changes to this bug.