BestSolution-at / fixtar

extract data from corrupted tar files
GNU General Public License v2.0
42 stars 9 forks source link

"memory: Cannot allocate memory" #1

Open kostich opened 8 years ago

kostich commented 8 years ago

I am unable to execute first step in tar recovery. I've inputted

ft < archive.tar.bz2 > archive.tar.bz2.repaired

and I got message memory: Cannot allocate memory. Archive.tar.bz2 is an 13 GB large tar archive and the computer has about 6 gigs of RAM in it.

The OS is CentOS 6.7. Latest revision.

daudo commented 8 years ago

sorry for the late response. I just tried to reproduce with a 16GB large archive and even though it took some time, it worked as intended. Any further pointers like OS, RAM, exact error message you get?

kostich commented 8 years ago

Sadly, no. All the info I had I have already posted in my first message.

sebastianlutter commented 5 years ago

Have the same issue with memory: Cannot allocate memory. Build and install was without issues.

Debian 9, x86_64

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           6942        2190        1862          62        2890        4389
Swap:          1023         164         859

The tar file has a size of 750MB:

$ ls -lh images_part_a_smaller_rpi1gg_images.tar
-rw-r--r-- 1 user user 716M May 17 19:07 images_part_a_smaller_rpi1gg_images.tar

$ ft < images_part_a_smaller_rpi1ji_images.tar > images_part_a_smaller_rpi1ji_images_ft.tar
memory: Cannot allocate memory

Maybe strace outputs helps:

$ strace ft < images_part_a_smaller_rpi1ji_images.tar > images_part_a_smaller_rpi1ji_images_ft.tar
[ ... ]
read(0, "(\5\0\240\24\6\17Y\351\10:\342\300\375\246\341\342%\247\nV\207\231!.2\342HR\34A "..., 4096) = 4096
write(1, "q.,\270r[t4\227\25\31R\33\vIq\235\370#j\302v\220r;dv\256\373!\314\236"..., 4096) = 4096
read(0, "wv]\27\355\334\253)v\276\352\376\263\352\217\312'Uj9\267\224DAm\226\236)Ci\7\31"..., 4096) = 4096
write(1, "Je\201\256\324\221@(\5\0\240<W[<+\344\7\241\\\"\263:#\311)q\211\r\205\241`"..., 4096) = 4096
read(0, "\t=\217\245o\317\206\31\307-J\231K\212\371\2574\357g\242I\253[^\372Z\312\345$Z\1\332"..., 4096) = 4096
write(1, "\206\243\27R\242ru\32\326\362\225\233{\352\226\327\362\277S\217\2519\370E\351=\311\32\342~\241\277"..., 3072) = 3072
read(0, "%\265\310\17\254\0256\263\3616\352|\320\241\310\377\0:\323\257mV\326[5\27\330\332\241uJ\352"..., 4096) = 4096
read(0, "Z\2609$g\246O,\366\246BFkPE\202\213m\256K\20\315\266T\222\265\30\276*\227\226\207"..., 4096) = 4096
read(0, "\372\37\2237\21\257\247Q\307R\303\361[\215\377\0_p\352.\251\206\2454\220\334\204\214\245C\261\250"..., 4096) = 4096
mmap(NULL, 125538104094720, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
brk(0xce65d9afc000)                     = 0x5c38bb961000
mmap(NULL, 125538104225792, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x722d16196000
munmap(0x722d16196000, 31891456)        = 0
munmap(0x722d1c000000, 35217408)        = 0
mprotect(0x722d18000000, 135168, PROT_READ|PROT_WRITE) = 0
mmap(NULL, 125538104094720, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory)
dup(2)                                  = 3
fcntl(3, F_GETFL)                       = 0x8402 (flags O_RDWR|O_APPEND|O_LARGEFILE)
fstat(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
write(3, "memory: Cannot allocate memory\n", 31memory: Cannot allocate memory
) = 31
close(3)                                = 0
lseek(0, -1100, SEEK_CUR)               = 5729204
exit_group(1)                           = ?
+++ exited with 1 +++

Do I really need more RAM or is this a bug?

daudo commented 5 years ago

Looks like a bug, I'll have a look at it

tronar commented 1 year ago

I would say some corruption can lead to this. The tool has 2 ways of ingesting records and presumes there can be no 2 extension records one after the other. I've run into a case where this is not true (and also some checksums getting wrongly calculated). The no memory comes from missinterpreting a header size, not from low memory.

telepath commented 2 weeks ago

So, is there any way to solve this? I have a 55GB tar file that gives me the "cannot allocate memory" error.

tronar commented 2 weeks ago

In my case I had to do it by hand...