Project

General

Profile

Actions

Emulator Issues #2569

closed

Compressing Small ISOs Results in Crash

Added by kolano over 14 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

What steps will reproduce the problem?

  1. Compress a small Gamecube ISO image, such as...
    -Game Boy Player Start-up Disc for EUR (E) (UGPP01)
    -QFC: The Tower of Druaga (J) (PKBJ01)

What is the expected output?
"Compressing ISO" dialog displays, progresses to 100% completion, is
exitable and results in a usable compressed gcz file.

What do you see instead?
"Compressing ISO" dialog displays, shortly thereafter Dolphin crashes. A
0byte file with the appropriate filename is produced.

What version of the product are you using? On what operating system?
r5286 x64 Windows 7

Please provide any additional information below.
This likely effects small Wii ISOs as well, but the sys update content on
most discs likely puts them above the largest applicable size here.


Related issues 1 (0 open1 closed)

Has duplicate Emulator - Emulator Issues #2543: Crash when attemping to compress a isoDuplicate

Actions
Actions #1

Updated by lpfaint99 over 14 years ago

i remember 'fixing' this locally a while back, if i remember correctly it is due to
only needing one compressed block. i'll try to find my patch, but i believe it was
hacky.

this is not a common scenarios as it requires the garbage data to be removed with
gcm-tool (or a similar program) and only applies to three games that i am aware of,
the two that you mentioned and action replay

Actions #2

Updated by fmendez89 over 14 years ago

I was having the same issue, nÂș2543. The problem is compressing ISO's not *.gcz files.
That's what I think.

Actions #3

Updated by Anonymous over 14 years ago

strange, I have compressed very small images fine...is this an issue that appeared kinda recently? (whenever
someone messed with that code last)
for instance, I have GB Player and Action Replay discs compressed...

nice that you already know the reason behind the issue though, lpfaint :)

Actions #4

Updated by lpfaint99 over 14 years ago

my memory wasnt the best but i was close :p

caused by i%0, code has been there since at least r566
line 222 (compressing) and line 321 (decompressing) cause this issue
my patch was to simply comment out these lines, but a better fix would be to check
for num_blocks < 1000

Actions #5

Updated by Anonymous over 14 years ago

  • Status changed from New to Accepted

OK, will take a look sometime...or maybe you can :p

Actions #6

Updated by lpfaint99 over 14 years ago

here's a crappy quickfix with a drawback of no progress bar for the games that it affects

Index: Source/Core/DiscIO/Src/CompressedBlob.cpp

--- Source/Core/DiscIO/Src/CompressedBlob.cpp (revision 5384)
+++ Source/Core/DiscIO/Src/CompressedBlob.cpp (working copy)
@@ -216,10 +216,11 @@
u64 position = 0;
int num_compressed = 0;
int num_stored = 0;

  • int progress_monitor = max(1, header.num_blocks / 1000);

    for (u32 i = 0; i < header.num_blocks; i++)
    {

  •   if (i % (header.num_blocks / 1000) == 0)
    
  •   if (i % progress_monitor == 0)
      {
      	u64 inpos = ftell(inf);
      	int ratio = 0;
    

@@ -315,10 +316,11 @@
FILE* f = fopen(outfile, "wb");
const CompressedBlobHeader &header = reader->GetHeader();
u8* buffer = new u8[header.block_size];

  • int progress_monitor = max(1, header.num_blocks / 100);

    for (u64 i = 0; i < header.num_blocks; i++)
    {

  •   if (i % (header.num_blocks / 100) == 0)
    
  •   if (i % progress_monitor == 0)
      {
      	callback("Unpacking", (float)i / (float)header.num_blocks, arg);
      }
    
Actions #7

Updated by Anonymous over 14 years ago

Issue 2543 has been merged into this issue.

Actions #8

Updated by Anonymous over 14 years ago

i just realized that this only happens when you're using a modified image (read:
[poorly] pirated)
that makes me unenthusiastic.

Actions #9

Updated by lpfaint99 over 14 years ago

for most instances i'm sure that you're right about this happening (poorly pirated
games), i spend (waste?) the time to throw out garbage data with gcmtool and than
compress with dolphin. when I ripped action replay the original gcm was 31Mb (ar
1.06 ntsc)

Actions #10

Updated by Anonymous over 14 years ago

well, i honestly cannot think of a better way than checking num_blocks before the loop is entered, can you? (it is
actually an interesting logic problem, to me :) )
also, why are we using 100 as the interval for decompressing, and 1000 for compressing? the number of blocks
will be the same in each case.

Actions #11

Updated by Anonymous over 14 years ago

  • Status changed from Accepted to Fixed

This issue was closed by revision r5433.

Actions

Also available in: Atom PDF