Crash after DB upgrade with version 1.7.0

[svendickman]

Hello,
First of all, I love your program and have been using it for years. Since the arrival of the Android https://github.com/moneymanagerex/android-money-manager-ex/releases version compatible with v1.7 I decided to upgrade.
The upgrade works fine on my android, but I cannot open the database on my Windows PCs (I've tried 2 different Win10) and have the exact same error.
I've tried the 32bit and 64bit portable versions. The upgrade of the DB seems to perform correctly, but when I try to open the upgraded DB it stops with in the XML debug file.
The DB can be opened with Android version. If I export the DB in the android I still have the same results.

Thanks for any help you can provide
Sven

Attached is the debug report

MMEX version:

• 1.6.4
• 1.7.0
• 1.7.1
• 1.7.2
• Other (please specify)

Note: bug reporters are expected to have verified the bug still existsMoneyManagerEx_dbgrpt-15448-20240110T110254.zipcode
(master branch).

Operating System:

• Windows
• Mac OSX
• Linux

Description of the bug

Please describe your issue with details.
Add screenshot or other files if needed.

Reproduction

Is the bug reproducible?

• Always
• Randomly
• Happened only once

Reproduction steps:

Expected result:

Actual result:

Additional information

If you have a backtrace for a crash or a warning, paste it here.

[whalley]

Does this Beta build fix the issue?
https://ci.appveyor.com/project/whalley/moneymanagerex/build/job/23h22hk9chsyjn33/artifacts

Possibly this issue - #6390

[svendickman]

Hello, Thanks for your reply. The behavior remains the same with this beta build. Sincerely, Sven

…

On Wed, Jan 10, 2024 at 10:07 PM Mark Whalley ***@***.***> wrote: Does this Beta build fix the issue? https://ci.appveyor.com/project/whalley/moneymanagerex/build/job/23h22hk9chsyjn33/artifacts Possibly this issue - #6390 <#6390> — Reply to this email directly, view it on GitHub <#6449 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH262ZFMWBP3AWJS74BIYQDYN37I3AVCNFSM6AAAAABBURG3L6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBVG4ZTINBTGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[n-stein]

Which version did you upgrade from? Did you perform the upgrade on Android or Windows?

[svendickman]

Which version did you upgrade from? Did you perform the upgrade on Android or Windows?

Hello n-stein. I was previously MMEX 1.5.15 on Windows and MMEX Android 2019.02.12.991. (DB version 17 I believe.)

The result is the same if I upgrade the DB on the Windows application or on the Android.

I have also tried deleting all of the recurring transactions in the upgraded DB, the result is still the same.

[renato-mmex]

Are there any other error messages?

[whalley]

Easiest way to debug this is if you could send your database to support@moneymagerex.org. I can assure you that the database will only be used to debug this issue and will be deleted once complete. Feel free to anonymise any information in the database so long as it still fails as you described.

[svendickman]

After some long trials and errors in deleting certain transactions and accounts I have narrowed the error down to something in stocks and shares. After removing some portfolios and then upgrading the DB the app no longer crashes on startup.
If developers are interested in trying to debug the issue I can try and isolate the issue and share a simplified DB.
Thank you for your interest and help
Sven

[whalley]

Yes it is something that got corrupted in the DB.

Having looked at this it crashes here...

moneymanagerex/src/model/Model_Stock.cpp

Line 311 in 1edc0df

total_shares += share_entry->SHARENUMBER;

But as a result of this code

moneymanagerex/src/model/Model_Stock.cpp

Lines 300 to 304 in 1edc0df

	for (const auto trans : trans_list)
	{
	Model_Checking::Data* checking_entry = Model_Checking::instance().get(trans.CHECKINGACCOUNTID);
	if (checking_entry && checking_entry->DELETEDTIME.IsEmpty()) checking_list.push_back(*checking_entry);
	}

which does not filter out a TransLink to a transaction that does not exist - how it got in that state I don't know.

It's actually returning an empty 'checking_entry' with TRANSID = -1 rather than a null pointer.

Perhaps we should develop something to integrity check the database and offer fixes... think it has been discussed before....