Bug 139184 - KSpread crashes when FILE.xls is too big
Summary: KSpread crashes when FILE.xls is too big
Status: RESOLVED FIXED
Alias: None
Product: calligrasheets
Classification: Applications
Component: filters (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR crash
Target Milestone: ---
Assignee: Ariya Hidayat
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-23 23:42 UTC by Robert Moore
Modified: 2009-01-14 20:32 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Spreadsheet workbook (52.00 KB, application/msexcel)
2007-01-01 00:33 UTC, Robert Moore
Details
ditto (70.50 KB, application/msexcel)
2007-01-01 00:34 UTC, Robert Moore
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Moore 2006-12-23 23:42:47 UTC
Version:            (using KDE KDE 3.5.5)
Installed from:    Ubuntu Packages
OS:                Linux

I have two Excel .xls files (generated by and downloaded from fastinfo.no) that each contain only one worksheet listing text and numbers. One is large and the other much smaller. The smaller one loads successfully and the larger one crashes KSpread while it is loading the file. Crashes occur whether KSpread opens the file or the file is opened from Konqueror.

The sizes for working files are less than 0·5MB, the crashing file is 9·7MB. 

The worksheets hold no formula or function cells. My current Linux setup has only limited free disk space.
Comment 1 Bram Schoenmakers 2006-12-23 23:55:53 UTC
Please provide a backtrace.
Comment 2 Robert Moore 2006-12-24 00:22:44 UTC
Attempt #1:

This backtrace appears to be of no use.
This is probably because your packages are built in a way which prevents creation of proper backtraces, or the stack frame was seriously corrupted in the crash.

Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1231690064 (LWP 8933)]
0xffffe410 in __kernel_vsyscall ()
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7dcee40 in nanosleep () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7dcec8f in sleep () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7890329 in KCrash::startDrKonqi (argv=)
    at /build/buildd/kdelibs-3.5.5/./kdecore/kcrash.cpp:311
Comment 3 Robert Moore 2006-12-24 00:28:25 UTC
Attempt #1 was from within KSpread (I was also browsing my webmail with two Konqueror windows open and a mix of local and remote tabs open). Here is attempt #2, which was opened from Konqueror:

Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1231690064 (LWP 9057)]
[KCrash handler]
#6  0xffffe410 in __kernel_vsyscall ()
#7  0xb7d69770 in raise () from /lib/tls/i686/cmov/libc.so.6
#8  0xb7d6aef3 in abort () from /lib/tls/i686/cmov/libc.so.6
#9  0xb7f5a520 in __gnu_cxx::__verbose_terminate_handler ()
   from /usr/lib/libstdc++.so.6
#10 0xb7f57f55 in std::set_unexpected () from /usr/lib/libstdc++.so.6
#11 0xb7f57f92 in std::terminate () from /usr/lib/libstdc++.so.6
#12 0xb7f580ca in __cxa_throw () from /usr/lib/libstdc++.so.6
#13 0xb7f5850e in operator new () from /usr/lib/libstdc++.so.6
#14 0xb7f585ed in operator new[] () from /usr/lib/libstdc++.so.6
#15 0xb7607e3d in QString::setLength () from /usr/lib/libqt-mt.so.3
#16 0xb7634fde in QUtf8Decoder::toUnicode () from /usr/lib/libqt-mt.so.3
#17 0xb7554bf0 in QXmlInputSource::fromRawData () from /usr/lib/libqt-mt.so.3
#18 0xb755520b in QXmlInputSource::fetchData () from /usr/lib/libqt-mt.so.3
#19 0xb75553d9 in QXmlInputSource::QXmlInputSource ()
   from /usr/lib/libqt-mt.so.3
#20 0xb6707ea8 in KoOasisStore::loadAndParse ()
   from /usr/lib/libkofficecore.so.3
#21 0xb670ad75 in KoDocument::loadOasisFromStore ()
   from /usr/lib/libkofficecore.so.3
#22 0xb67145f1 in KoDocument::loadNativeFormatFromStore ()
   from /usr/lib/libkofficecore.so.3
#23 0xb6714e5a in KoDocument::loadNativeFormat ()
   from /usr/lib/libkofficecore.so.3
#24 0xb6729846 in KoDocument::openFile () from /usr/lib/libkofficecore.so.3
#25 0xb7fb18de in KParts::ReadOnlyPart::openURL (this=0x81b9758, 
    url=@0xbff47000) at /build/buildd/kdelibs-3.5.5/./kparts/part.cpp:344
#26 0xb670284a in KoDocument::openURL () from /usr/lib/libkofficecore.so.3
#27 0xb66d4a63 in KoMainWindow::openDocumentInternal ()
   from /usr/lib/libkofficecore.so.3
#28 0xb6702e66 in KoMainWindow::openDocument ()
   from /usr/lib/libkofficecore.so.3
#29 0xb67170f8 in KoApplication::start () from /usr/lib/libkofficecore.so.3
#30 0xb67eb0bd in kdemain () from /usr/lib/libkdeinit_kspread.so
#31 0xb67fe510 in kdeinitmain () from /usr/lib/kde3/kspread.so
#32 0x0804e4df in launch (argc=2, _name=0x8104fdc "kspread", 
    args=0x8105030 "", cwd=0x0, envc=1, envs=0x8105041 "", reset_env=false, 
    tty=0x0, avoid_loops=false, 
    startup_id_str=0x8105046 "rob-laptop;1166916311;250129;8073_TIME2980173819") at /build/buildd/kdelibs-3.5.5/./kinit/kinit.cpp:673
#33 0x0804ed6a in handle_launcher_request (sock=10)
    at /build/buildd/kdelibs-3.5.5/./kinit/kinit.cpp:1240
#34 0x0804f118 in handle_requests (waitForPid=0)
    at /build/buildd/kdelibs-3.5.5/./kinit/kinit.cpp:1443
#35 0x080503ac in main (argc=5, argv=0xbff47bb4, envp=0xbff47bcc)
    at /build/buildd/kdelibs-3.5.5/./kinit/kinit.cpp:1909
#36 0xb7d558cc in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#37 0x0804b971 in _start ()
Comment 4 Tomas Mecir 2006-12-24 11:16:51 UTC
Sounds like it threw an exception due to running out of memory.
Comment 5 Robert Moore 2006-12-24 12:14:35 UTC
Sure, but not the most graceful exit. It would be better to let the user know the file's to big, and opening only as much as possible without using whatever inadequate swap the may be.

Anyone know a link to the relevant http://lxr.kde.org/ section?
Comment 6 Tomas Mecir 2006-12-24 13:16:33 UTC
Yes, I'm not saying that it's okay, just what caused the problem. The
exception will need to be caught and handled somewhere. Somehow.
Comment 7 Ariya Hidayat 2006-12-31 11:56:17 UTC
Which version are you using (see Help, About menu) ?

Can you attach the files so I can have a look ?
Comment 8 Robert Moore 2007-01-01 00:33:13 UTC
Created attachment 19074 [details]
Spreadsheet workbook

The larger of the uploaded file(s) crashed the app.
Comment 9 Robert Moore 2007-01-01 00:34:24 UTC
Created attachment 19075 [details]
ditto
Comment 10 Robert Moore 2007-01-01 00:44:22 UTC
I got "The file you are trying to attach is 9974 kilobytes (KB) in size. Non-patch attachments cannot be more than 1000KB. If your attachment is an image, try converting it to a compressable format like JPG or PNG, or put it elsewhere on the web and link to it from the bug's URL field or in a comment on the bug."

Screenshots would be impossible/pointless because the data in the spreadsheet is the same as what is already uploaded, only a dozen times as many rows.
Comment 11 Robert Moore 2007-01-01 00:48:25 UTC
(Attachments 19074 and 19075 did not crash it.)
Comment 12 Robert Moore 2007-01-01 01:25:33 UTC
In the process of reinstalling Kubuntu Edgy (KDE 3.5·5) I increased my root partition from a mostly used 9GB to a mostly free 19GB (12GB free right now). The 2GB linux-swap partition remains the same size. More space in the root partition appears to have resulted in KSpread continuing to try to load the file for more than twenty minutes, with a lot of disk activity but nothing else to see.
Comment 13 Stefan Nikolaus 2007-07-28 08:18:42 UTC
Can you send me the file (#10) per private mail, so I can check it with KSpread's development version?
Comment 14 Marijn Kruisselbrink 2009-01-14 20:32:37 UTC
SVN commit 911067 by mkruisselbrink:

some big optimizations in the excel import filter, both in the code itself (nearly 1000 lines of code less), and in the ods files generated; properly merge styles, making huge excel files load a lot faster with a lot less memory in kspread
BUG: 139184


 M  +321 -1276 excelimport.cc  


WebSVN link: http://websvn.kde.org/?view=rev&revision=911067