Bug 143859 - Crash in: Jrd::Sort::order() Loading 28.3 MG odb file created in 7.2.03.RC
Summary: Crash in: Jrd::Sort::order() Loading 28.3 MG odb file created in 7.2.03.RC
Status: RESOLVED DUPLICATE of bug 144340
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
7.2.0.2 rc
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-08-13 19:23 UTC by Brant Maltby
Modified: 2021-09-12 22:29 UTC (History)
1 user (show)

See Also:
Crash report or crash signature: ["Jrd::Sort::order()"]


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brant Maltby 2021-08-13 19:23:04 UTC
This bug was filed from the crash reporting server and is br-396d4827-7958-42f2-98bd-1bdff23f91a7.
=========================================

File opens in 7.1.5.2.  Had fixed column lengths in master record for each table in the file, but the large 880K row file would not load even with fix - base crashed.  Deleted file and reloaded from calc.  It loaded and saved, but when closed and then reopened, base crashed.
Comment 1 Julien Nabet 2021-08-18 13:33:57 UTC
It could be interesting to try to Firebird directly.
I mean, it's perhaps a Firebird bug and not a LO bug since the bt shows internal part of Firebird.

About "7.2.0.5 with the calc file losing 1000 rows when saving", do you mean the pb that when we save more than 1000 rows in xls/xlsx, it keeps only the first 1000 rows? if yes, it corresponds to tdf#143896.

BTW, please comment in bugtracker instead of sending me an email.
You can put me in cc of a bugtracker if you want me to be notified by comments on a bugtracker. (for this one, I've just done it).
Comment 2 Brant Maltby 2021-08-27 11:35:02 UTC
7.2.1.1 crashes when attempting to load file.
Comment 3 Brant Maltby 2021-08-27 18:39:41 UTC
Update of 7.2.1.1:

LINUX WORKS: 

Same computer, dual booted into Zorin 16 Linux.  Updated 7.1.6.1 to 7.2.1.1.  This was not straight forward as the standard purge did not eliminate a 7.1.5 Zorin update to Libre Office core.  Using Synaptic I eliminated the remainder of the Zorin Libre office core update.  I then updated to 7.2.1.1.  The file opened and I was able to access the 880,000 row table, confirm the total rows, confirm the amount check total, perform a simple query and save changes.

BACK TO WINDOWS 10:

I rebooted into windows and attempted to have 7.2.1.1 open the file I had just accessed in Linux -- it crashed.

After the problems in Linux updating to 7.2.1.1 I decided to do a fresh install.  I uninstalled 7.2.1.1 and cleaned the registry, rebooted, and did a clean install -- when I attempted to access the file, 7.2.1.1 crashed.

It appears there is something about Windows 10, my configuration and/or Firebird for Windows that may be causing the crash.

I note that I have copied over my Windows Libre Office configuration file to Linux and while there may be some differences the files are substantially the same.
Comment 4 Roman Kuznetsov 2021-08-28 18:19:12 UTC
Can you show us your 28 MB odb file?
Comment 5 Brant Maltby 2021-08-29 17:07:18 UTC
No - cannot -- client data.

ADDITIONAL INFORMATION:

Included in the 28.3 mg file is the 880,000 row/17 field table.  Without this table the file will open in Windows 10 7.2.1.1, with it LibreOffice crashes.

Another smaller file, 5.83 mg has a table that is 183,000 rows and 27 fields, and it loads in Windows 7.2.1.1.
Comment 6 Julien Nabet 2021-08-29 17:26:23 UTC
Can't help here=>uncc myself
Comment 7 Roman Kuznetsov 2021-08-29 18:07:49 UTC
Without the file we can't check and can't try search a problem, sorry
Comment 8 Brant Maltby 2021-09-12 20:10:24 UTC
Windows crash when loading 28.3 mg files appears to be resolved in 20210911 daily.

Note that Windows FB configuration was updated among other FG commits subsequent to 7.2.1.2.
Comment 9 Mike Kaganski 2021-09-12 21:09:43 UTC
Most likely tdf#144340.
Comment 10 Roman Kuznetsov 2021-09-12 22:29:26 UTC

*** This bug has been marked as a duplicate of bug 144340 ***