Bug 333236

Created attachment 86019 [details]
On the computer this fails on this causes an illegal instruction on scheduled transactions

This was discovered on an AMD 64-bit system with the following characteristics:

$ uname -a
Linux silvermine 3.11.0-19-generic #33-Ubuntu SMP Tue Mar 11 18:48:34 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

lsb_release -a
No LSB modules are available.
Distributor ID:	LinuxMint
Description:	Linux Mint 16 Petra
Release:	16
Codename:	petra

$ cat /proc/cpuinfo 
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 16
model		: 4
model name	: AMD Phenom(tm) II X4 965 Processor
stepping	: 2
microcode	: 0x10000db
cpu MHz		: 800.000
cache size	: 512 KB
physical id	: 0
siblings	: 4
core id		: 0
cpu cores	: 4
apicid		: 0
initial apicid	: 0
fpu		: yes
fpu_exception	: yes
cpuid level	: 5
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save
bogomips	: 6817.06
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

libgmp-dev is version 2:5.1.2+dfsg-2ubuntu1

The exact version of libgmp and libalkimia4 on the system that is failing is:

libgmp10:amd64 (2:5.1.2+dfsg-2ubuntu1)
libgmp-dev:amd64 (2:5.1.2+dfsg-2ubuntu1)
libalkimia4_4.3.2-1.1_amd64.deb (4.3.2-1.1)

I have attempted to delete all schedules manually which allows me to open the file on the affected computer but I am unable to perform an OFX update as it immediately crashes with the same error.  I'll continue to investigate but I'm not sure what else to try.

Based on the original trace, there's something weird happening. Here's the relevant snippet of code.

      MyMoneyMoney balance;
      if (balances.count() == 0)
        balance = MyMoneyFile::instance()->balance(acc.id(), dueDate.addDays(-1));
      else
        balance = balances[acc.id()];

      // FIXME: for now, we only support interest calculation at the end of the period
      calc.setBep();
      // FIXME: for now, we only support periodic compounding
      calc.setDisc();

      calc.setPF(MyMoneySchedule::eventsPerYear(schedule.occurrence()));
      MyMoneySchedule::occurrenceE compoundingOccurrence = static_cast<MyMoneySchedule::occurrenceE>(acc.interestCompounding());
      if (compoundingOccurrence == MyMoneySchedule::OCCUR_ANY)
        compoundingOccurrence = schedule.occurrence();

      calc.setCF(MyMoneySchedule::eventsPerYear(compoundingOccurrence));

      calc.setPv(balance.toDouble());   <--- this is line 1264.

I think the only way this might happen, is if QMap balances does not actually contain acc.id(), but it should still return a default MyMoneyMoney value, which is 0, and is a normal case

There is a very real possibility that the way I structured the loan(s) in that file is the problem.  Even in anonomized form you can see that something is fishy.  I don't want to publicly disclose too much data about the loan(s) but suffice it to say I configured it such that no payments would be scheduled until the last day but interest would calculate as being accrued for the duration of the loan (i.e. sort of like a non-compounded loan with a baloon payment, although this grossly miscategorizes the actual intent of the loan - like I say, I have to walk a fine line between describing the loan without creating incorrect public assumptions :).

I tried removing the schedules from the loan but it was still not possible to use OFX connect.  I can try eradicating the questionable loan(s) altogether as a next step; I have fairly high confidence that the problem will go away.

Created attachment 86045 [details]
Crash log from clicking on forecast charts when no loans are present

I've now deleted every loan with unusual characteristics but simple things such as going to forecast charts or doing an OFX update still cause the illegal instruction.  I'm starting to really suspect libgmp and I'm tempted to figure out how to build *that* from source next.

I could bet that it's libgmp since it uses CPU specific assembly code which, if not built for the correct platform, would result in this kind of error.

With help from Hei_Ku in #kmymoney I've compiled everything *extremely* cleanly by doing make distclean and make clean on everything.  I then built libgmp 5.1, built libalkimia, built kymymoney, and reproduced the same crash: http://codepad.org/BSk0sM4l

As an aside, I completed a full memory scan and found no errors.  I've also done a make test on kmymoney with the result "100% tests passed, 0 tests failed out of 30".  I consistently see crashes when using my non-anonomized file to do an OFX or by going to forecast -> charts.  A test of doubles in libgmp is likely needed next, per Hei_Ku.

There are crashes both when instantiating a new MyMoneyMoney from a double, and when calling  method toDouble.
I'm adding an additional test in mymoneymoneytest to check these cases, both of which are not tested at the moment.

After Alvaro's changes, the make test still reports 100% tests passed, 0 tests failed out of 30.  Making changes such as adding .toString() everywhere gets around the crash but causes the units to be off in difficult to understand ways when doing an OFX import, such as an $86.00 transaction showing up as $0.08 but a later transaction showing up with the correct value.

What's the status of this issue? Can the crash be reproduced using the attached anonymous file?

The anonymous file opens without any issues over here, you said you built libgmp yourself while testing with Alvaro, did the gmp tests run without failure?

I have done some additional testing on this issue and I am unable to recreate it after booting from Linux Mint 17 on the *exact same hardware*.  I can only assume that the initial swap of the CPU caused an extremely deep bug that will hopefully never blight anyone ever again.  For now, I believe this is not reproducible but this public record can stand as a monument to any who follow this rabbit hole.

OK, thanks for the follow-up.