Bug 182577 - Okteta unable to load large files
Summary: Okteta unable to load large files
Status: CONFIRMED
Alias: None
Product: okteta
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Friedrich W. H. Kossebau
URL:
Keywords:
: 253027 277553 311115 458712 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-01-31 13:57 UTC by Benjamin Schindler
Modified: 2022-09-04 21:16 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Schindler 2009-01-31 13:57:43 UTC
Version:            (using KDE 4.2.0)
OS:                Linux
Installed from:    Gentoo Packages

When I open A file in okteta which is of 6gb size (64bit system), okteta crashes with: 
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
KCrash: Application 'okteta' crashing...
sock_file=/home/benjamin/.kde4/socket-metis/kdeinit4__0
okteta: Fatal IO error: client killed

I interpret this as okteta trying to allocate memory for the entire file. But this is not needed! Just load the parts you need for display (+some) and load ondemand when needing other parts, freeing when parts are not used anymore.
There are other hexeditors out there which do this correctly. It would be great if okteta would too

Thanks
Comment 1 Friedrich W. H. Kossebau 2009-01-31 14:23:52 UTC
Thanks for your report. This is a known problem (see http://utils.kde.org/projects/okteta/faq.php) from the start, but the support in the code is not yet completed. Please be patient :) Some future version will hopefully finally be capeable, no promises which it will be. 
Comment 2 Peter Cordes 2009-11-08 21:24:47 UTC
When Okteta has large file support, please let it work on block devices, too.

I tried it on a block dev, and it thinks the file has zero length.  Obviously that's a better failure mode than trying to load the whole block dev into RAM. 

BTW, someone was working on large file/in-place editting support for ghex,
and maybe designing a class that would work like a regular document, but load regions from the large file on the fly, as needed.  That probably never got anywhere, though.

 There was some discussion about how a hex editor should work (overwrite in place vs. save to new file), and stuff...  you may want to read
https://bugzilla.gnome.org/show_bug.cgi?id=91494

 Although Okteta already seems to rewrite in-place, it does truncate the file in the process (O_WRONLY|O_CREAT|O_TRUNC), which is not what I'd expect a hex editor in overwrite mode to do.  Not sure how this might interact with another process which had e.g. a disk image file memory mapped.
Comment 3 Friedrich W. H. Kossebau 2010-06-22 23:41:42 UTC
Doesn't crash in the latest version, while still unable to load large files, so downgrading from "crash" to "normal".
Hopefully one day I finally get to fix this...
Comment 4 Christoph Feck 2010-10-02 16:10:08 UTC
*** Bug 253027 has been marked as a duplicate of this bug. ***
Comment 5 Friedrich W. H. Kossebau 2011-07-11 18:42:14 UTC
*** Bug 277553 has been marked as a duplicate of this bug. ***
Comment 6 Christoph Feck 2012-12-04 14:23:05 UTC
*** Bug 311115 has been marked as a duplicate of this bug. ***
Comment 7 Alessandro Di Federico 2013-01-06 09:17:20 UTC
I think that a quick workaround could be to be able to open a portion of a file.
Comment 8 kdebugs 2014-03-29 06:05:37 UTC
(In reply to comment #1)
> http://utils.kde.org/projects/okteta/faq.php

Link doesn't work.  Maybe http://userbase.kde.org/Okteta is better?
Comment 9 Soukyuu 2016-01-23 16:40:11 UTC
Any good alternatives since this is still not fixed?
Comment 10 Friedrich W. H. Kossebau 2016-01-23 19:55:27 UTC
Hi Soukyuu. You could have a look at http://www.wxhexeditor.org/. Not tried myself, but it was done especially for the purpose to also read large files and complete filesystems.
Comment 11 Friedrich W. H. Kossebau 2022-09-04 21:16:58 UTC
*** Bug 458712 has been marked as a duplicate of this bug. ***