grub4dos
grub4dos copied to clipboard
map --unmap hanging on non-contiguous ISO file

HANG !!!!!
Works OK on contiguous files...

OK

2019-07-26 FAILS 2018-06-12 FAILS
map (0xff) (0xff) also hangs
There seems to be a memory corruption problem with the code which maps a non-contiguous file.
Easy2Boot temporarily maps, hooks and unmaps many ISOs. I remove unmap (because it hangs if file is not contiguous) and so I get just map and hook commands (one for each file)
e.g.
map /xx.iso (0xff)
hook
map /yy.iso (0xff)
hook
map /zz.iso (0xff)
hook
... more files....
If I then execute a menu item configfile /menu.lst then it returns to the Main menu. This works OK.
However, if file yy.iso is not contiguous, then the configfile command hangs (clears screen - no cursor)!
The only thing I changed was to remove the non-contiguous yy.iso file. If I add yy.iso then the configfile menu entry hangs when executed. If I remove the yy.iso file then it all works. So just the act of mapping the non-contiguous file is making the configfile command hang.
I'm testing normal here. It may be that there are too few file fragments. Please provide ISO for recurrence of the problem.
https://support.kaspersky.com/viruses/krd18 - download directly from internet in Chrome and straight onto a USB drive (do not copy file from HDD to USB) - downloading via browser will create a fragmented file. I do not think the problem is the ISO (I suspect any ISO would fail if it had similar number of fragments). I think you will have to make the ISO on an NTFS USB drive and copy and delete many small files so that you get a ISO file with many fragments. The ISO has approx 19 fragments - is this too many for grub4dos? How does grub4dos check if there are too many fragments? What is the limit for the number of fragments for map command in grub4dos?
Download to the U disk, it's not necessarily possible to generate so much debris. If only there were a small img document with enough fragments to reproduce the problem.
I have tried to make another fragmented file with just 15-20 fragments but it is very difficult!
I think the problem is to do with the number of fragments (or possibly size of each fragment) and memory corruption.
If you can make a debug version of grldr with debug info for map command and unmap command and fragments, then I can test for you. I suspect memory corruption issue...
so far 14 fragments seems OK. If too many fragments (e.g. 40) then map does not work and so does not hang. So problem is perhaps between 15 and 19 fragments???

That's the only way. Submit tomorrow.
Thanks to Wonko on reboot.pro I have found a fragmenter program.
Here is the fragment info the original 'bad' file


Here is another similar file with 19 fragments - this one is OK ...
Notice that the defragmenter has split the file evenly into blocks of '62984'


I have now found that a fragmented file with 32 fragments causes grub4dos to hang after the unmap.
New BAD file is:

Maybe if you use defragmenter on your krd ISO (on an NTFS drive) - it would show same issue?
MyFragmenter - https://1drv.ms/u/s!AqlrQcdsFA-KvhGa7IHCf2uve70X?e=aN1klI
Unable to download
https://app.box.com/s/vliurbplv1krk57gn1ku2zb7bu6ujdxl
Still unable to download
https://web.archive.org/web/20120420201724/http://www.mydefrag.com/Manual-DownloadAndInstall.html https://web.archive.org/web/20120517021802/http://www.mydefrag.com/Downloads/Download.php?File=MyDefrag-v4.3.1.exe You will need to install - then find the MyFragmentor.exe file.
USB drive , NTFS partition. krd.iso Fragment 32 . Test, no problem. However, some problems with fragmentation code were found. Why did it crash? Not clear. See if it solves the problem. grldr.rar.txt
The good news is that the unmap command does not hang now.
The bad news is that all fragmented files reported using blocklist as having only 2 fragments (even those with 40 fragments!)

Sorry for the confusion. The test version does report fragments correctly. Sorry ! Ignore my last report! Something went wrong with my USB drive it got corrupted and all files now have 2 fragments per file!!! Not sure what happened, I think Windows tried to fix the filesystem.
Anyway, the problem with the test version is still there I am afraid. I used MyFragmenter to make a 32 fragment file of krd.iso and it hangs with both the latest grldr and the new test grldr. So the problem is not fixed. You should be able to also make a 32-fragment krd.iso if you use MyFragmenter - it seems to reliably show the problem.
three files - all same contents. Only krd18.iso hangs. akrd.iso has 34 fragments - other two files have 32 fragments.

If I rename krd18.iso to krd18renamed.iso it still hangs.
"You should be able to also make a 32-fragment krd.iso if you use MyFragmenter - it seems to reliably show the problem." That's how it was tested. But it's normal.
map /xxxx/krd.iso (0xff) map --hook echo -mem=0xb6e0=0x290 map --unmap=0xff echo -mem=0xb6e0=0x290 See if the test is working? Are there any commands executed in the middle when hanging up?
Only 32 fragments!
Another error about fragmentation was eliminated. grldr.rar.txt