abrt version: 1.1.14 architecture: x86_64 Attached file: backtrace cmdline: gnumeric /home/karlh/Desktop/gnumeric-bugtest.gnumeric comment: The crash occurs because the constraint isn't preserved on the save and reload; instead of $A$1 >= 0 it says $A$1 >= #REF#. The solver doesn't check for the improper constraint on file open either. component: gnumeric crash_function: gnm_solver_constraint_get_part executable: /usr/bin/gnumeric-1.10.13 kernel: 2.6.34.7-66.fc13.x86_64 package: gnumeric-1:1.10.13-1.fc13 rating: 4 reason: Process /usr/bin/gnumeric-1.10.13 was killed by signal 11 (SIGSEGV) release: Fedora release 13 (Goddard) time: 1298674152 uid: 500 How to reproduce ----- Easily reproduced: 1. Open new file and enter random numbers in A1:A5 2. Set cell B1 to "=(A1-5)^2" and fill down to B5 3. Set cell B7 to "=SUM(B1:B5)" 4. Open Solver; tell it to set $B$7 -> Min by changing $A$1. 5. Add a constraint: $A$1 >= 0; click "Add" 6. Save the file and close it. 7. Open the file you just saved. 8. Open Solver and click "Solve".
Created attachment 481101 [details] File: backtrace
It happens here. CCing upstream.
Crash fixed here: http://git.gnome.org/browse/gnumeric/commit/?id=022c38d8aaa8cc093554f1e04c5c74766aa876f1 Saving is fine, but loading mangles the right-hand side. I'll have a look at that too.
Reading and a further problem fixed here. http://git.gnome.org/browse/gnumeric/commit/?id=7c2cdb4a0ef43eeabc1618df1d351395fbcd3970 However, results are still bogus, but that's your own fault: the model is not linear. Use the non-linear solver instead.
Should I patch the Fedora package with these, or would it be enough if the fix shipped with the next gnumeric version?
They'll ship with the next version in, I guess, a few weeks. That ought to be good enough. The reporter can build with patches if he really needs it before then.
Thank you for your prompt fixes---I look forward to the next version.