Android - Expense - App crashes when uploading a PDF receipt after uploading a photo receipt

[IuliiaHerets]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: 9.0.36-1
Reproducible in staging?: Y
Reproducible in production?: N/A - new feature, doesn't exist in prod
Email or phone of affected tester (no customers): [email protected]
Issue reported by: Applause Internal Team

Action Performed:

1. Launch New Expensify app.
2. Go to FAB > Submit expense > Manual.
3. Enter amount and select a user.
4. On confirmation page, tap 3-dot menu > Add receipt.
5. Add any photo receipt from device gallery.
6. On confirmation page with the photo receipt, tap 3-dot menu > Add receipt.
7. Select Choose file.
8. Select the PDF file (attached below) (happens with this PDF file only).
9. Might need to repeat Step 4 to 8 to reproduce the crash.

Expected Result:

App will not crash.

Actual Result:

App crashes when uploading a PDF receipt after uploading a photo receipt.

Workaround:

Unknown

Platforms:

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

1709.txt

Bug6606744_1726589183407.w_017c4be1d3a760522847c336971d21d3662a4686-2024-09-17_16_06_16.995.mp4

Bug6606744_1726588963019!International_Money_Transfer__Send_Money_Abroad_with_Wise__ex-TransferWise_.pdf

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @greg-schroeder (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Triggered auto assignment to @carlosmiceli (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[IuliiaHerets]

We think that this bug might be related to #wave-collect - Release 1

[grgia]

ongoing slack convos:
open-source: https://expensify.slack.com/archives/C02NK2DQWUX/p1726598780128409
deployer: https://expensify.slack.com/archives/C07J32337/p1726599054838339?thread_ts=1726595505.237429&cid=C07J32337

[mountiny]

Reopening to handle this update and fix the issue

[mountiny]

com.expensify.chat_issue_85c581edcdb39b941df627e7b1324a71_crash_session_66e8e6b7001c00016a8be1d135199580_DNE_0_v2_stacktrace.txt

--------- beginning of crash
09-17 23:58:21.532  8197  8703 E AndroidRuntime: FATAL EXCEPTION: PDF renderer
09-17 23:58:21.532  8197  8703 E AndroidRuntime: Process: com.expensify.chat, PID: 8197
09-17 23:58:21.532  8197  8703 E AndroidRuntime: java.lang.IllegalStateException: Already closed
09-17 23:58:21.532  8197  8703 E AndroidRuntime: 	at io.legere.pdfiumandroid.util.ConfigKt.handleAlreadyClosed(SourceFile:44)
09-17 23:58:21.532  8197  8703 E AndroidRuntime: 	at io.legere.pdfiumandroid.PdfPage.close(SourceFile:18)
09-17 23:58:21.532  8197  8703 E AndroidRuntime: 	at S5.J3.a(SourceFile:5)
09-17 23:58:21.532  8197  8703 E AndroidRuntime: 	at io.legere.pdfiumandroid.PdfiumCore.renderPageBitmap(SourceFile:6)
09-17 23:58:21.532  8197  8703 E AndroidRuntime: 	at x3.k.b(SourceFile:189)
09-17 23:58:21.532  8197  8703 E AndroidRuntime: 	at x3.k.handleMessage(SourceFile:7)
09-17 23:58:21.532  8197  8703 E AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:106)
09-17 23:58:21.532  8197  8703 E AndroidRuntime: 	at android.os.Looper.loopOnce(Looper.java:230)
09-17 23:58:21.532  8197  8703 E AndroidRuntime: 	at android.os.Looper.loop(Looper.java:319)
09-17 23:58:21.532  8197  8703 E AndroidRuntime: 	at android.os.HandlerThread.run(HandlerThread.java:67)
09-17 23:58:21.534  8197  8197 D jniPdfium: Destroy FPDF library
09-17 23:58:21.568  1912  1912 I Layer   : Layer [Sprite#2978] hidden!! flag(1)
09-17 23:58:21.569  2632  4778 I NSLocationMonitor: getGPSUsingApps() called
09-17 23:58:21.571  4757 15254 I NSLocationManager_FLP: getGPSUsingApps, NO_FREEZE={5013} / FREEZE={10235}
09-17 23:58:21.573  1912  1912 D SurfaceFlinger: Display 4630946213010294403 HWC layers:

[mountiny]

Some logs from the crash

[mountiny]

Asked SWM to look into this

[mountiny]

@j-piasecki @blazejkustra Who is working on this one? Can they please comment so I can assign them? thanks!

[j-piasecki]

I believe @Guccio163 is currently investigating this.

[Guccio163]

That's right, I'm Wiktor Gut from SWM, please assign me this issue

[Guccio163]

Hi, I'm just letting you know that it can take a little more time, I've reproduced this bug on current main; It can be not a package, but implementation problem - there are also similar bugs reported here encountered when updating RN from 0.71 to 0.74.5

[mountiny]

Interesting, we were not able to reproduce with many tries after revert

Thanks for the update

[Guccio163]

I understand, it is really non-deterministic - sometimes it goes after 4th try and sometimes doesn't break after 20th, this is the main reason why it takes time because is hard to test 🐢

[Guccio163]

Hi 👋 , I'm dropping by to let you know how the investigation is going; Fortunately problem proved to be linked to the reverted PR (version 6.7.5 of react-native-pdf library) and doesn't occur on current main - it turned out to be a local problem of android studio on my laptop when changing branches (solved today). Unfortunately, there are numerous issues linked to the 6.7.5 version crash (f.ex. wonday/react-native-pdf#830 and wonday/react-native-pdf#833). Some are left untouched and some contain solutions which doesn't work in our case. I'll keep investigating further with @j-piasecki 's help, we'll do out best to find the best suiting solution 🔜

[andrewhamili]

+1

[melvin-bot]

📣 @andrewhamili! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[Guccio163]

Hi 👋, I'm coming with some sort of conclusion, though not the perfect ending that we searched for; The problem itself lies somewhere inside the new version of the library.

Logs analysis and search:

Bug is inconsistent both in occurrence and causes what makes debugging noticeably harder; inconsistent occurrence was mentioned earlier and when it comes to causes, logs show one of 3 causes for crash:

• Parameter specified as non-null is null
• Already closed
• Already opened

Moreover logs produced by pdf library (blue ones) doesn't show anything unusual in terms of opening/closing documents, below comparison of logs without crash and resulting in crash. Both situations are chains close document->destroy library->draw pdf->init library->close document->destroy library:

• Working properly:

- Resulting in `Already closed` crash:

We suspect that it is caused by some sort of race condition within the native implementation, but it's really hard to notice when logs don't show anything strange.

Library problem:

Incorrect behaviour of the app is caused by the 6.7.5 version of the library itself reported in numerous issues (also caused whole app crash), some of them mentioned in previous comments; most of working solutions are based on going back to previous versions of the library. Moreover the react-native-pdf itself added native android library pdfiumandroid rewritten in Kotlin, which may be extra occasion for implementation errors (was previously in Java).

Purpose of reverted PR:

The whole purpose of @WoLewicki 's PR which was reverted to prevent this crash was to bump the library from 6.7.3 to 6.7.5, because 6.7.5 had merged a patch which was needed in 6.7.3; This way we could have just a newer version of the library without extra add-ons. Taking into consideration that 6.7.5 has unforeseen bugs, it would be meaningless to bump the library to newer version just to be forced to write new patches.

Solution:

Leave the PR reverted and keep the 6.7.3 version. It works great and without bugs as we already have them fixed, when the 6.7.5 would cause more of them.

cc @mountiny, WDYT?

[mountiny]

discussed in Slack here and we agreed that it's not worth spending more time here and we do not need to bump the library so until we would really need to use something from the newer version, we can pass

[roryabraham]

Rather than closing this outright, can we reopen it, make it a monthly, and put it on HOLD for the upstream issue?

That way this investigation isn't forgotten and we can upgrade the lib when the upstream issues are fixed (i.e: to remove patches and keep it up-to-date in case of security vulnerabilities and such)

[greg-schroeder]

I think we should actually close this, though, now that #vip-vsb is paused/closed/archived though, yes? That seems to be the conclusion per https://expensify.slack.com/archives/C03U7DCU4/p1727723600645479

Lemme know if you disagree or you think this could fit in a different project @roryabraham!

[melvin-bot]

@greg-schroeder @mountiny this issue was created 2 weeks ago. Are we close to a solution? Let's make sure we're treating this as a top priority. Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[mountiny]

Adding this to the newdot quality project and keeping it open so we can follow up in future once upstream is fixed @greg-schroeder feel free to unassign as there is nothing to do for you now

[mountiny]

waiting