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

Status: VERIFIED FIXED

(Socorro :: Backend, task)

Description

[Scoobidiver (away)]

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.

Comment 1

[Robert Kaiser]

This actually now is on the code of bug 863998, not the old code implemented in bug 726385.

Comment 2

[K Lars Lohn [:lars] [:klohn]]

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

Comment 3

[Scoobidiver (away)]

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.

Comment 4

[K Lars Lohn [:lars] [:klohn]]

noted. The corrective colon behavior is reverted leaving the corrective <addr> behavior intact.  

https://github.com/mozilla/socorro/pull/1261

Comment 5

[Scoobidiver (away)]

Can you provide the result of this algorithm for the two crash reports?

Comment 6

[K Lars Lohn [:lars] [:klohn]]

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)

Comment 7

[[github robot]]

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>

Comment 8

[Matt Brandt [:mbrandt]]

Thank you lars (comment 6 - bumping to QA verified. <3 Unit tests

Comment 9

[Scoobidiver (away)]

A colon is added for this signature and shouldn't: bp-546ebc06-ba5a-4400-9c9b-e4ec92130613.

Comment 10

[K Lars Lohn [:lars] [:klohn]]

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)

Comment 11

[Scoobidiver (away)]

(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.