libJPEG.dylib decode_mcu_optimized crash

[GoogleCodeExporter]

STR: Unzip the attached picture and load it with TFF 8.0 (G4 7450 version). The 
browser will crash. 

Crashlog consistently reads:

Thread 0 Crashed:
0   libJPEG.dylib                   0x95308250 decode_mcu_optimized + 300

Crashes: TFF 8.0 G4 7450, TFF 8.0b1 G4 7450
Does *not* crash: Safari 5.0.6, TFF 8.0 G3 version (!), TFF 7.0 (G4 7450 
version), FF 8.0 Windows.

NB: Photoshop reveals that jpeg is faulty (incomplete), but that's what we have 
to cope with on the web. 

Tested on PowerBook G4 7450 1.33 GHz, 10.5.8. I can't test G4 7400 and G5.

=> Altivec optimization bug?

Original issue reported on code.google.com by chtru...@web.de on 18 Nov 2011 at 12:49

Attachments:

• jpeg-crasher.jpg.zip

[GoogleCodeExporter]

Tobias?

Original comment by classi...@floodgap.com on 18 Nov 2011 at 4:13

[GoogleCodeExporter]

Also, 10.4 or 10.5? Just to see if it's a difference.

Original comment by classi...@floodgap.com on 18 Nov 2011 at 4:15

[GoogleCodeExporter]

The crash implies null pointer. However, I don't see anything in the backtrace 
that can catch that, unless we fed cg_jpeg_consume_input a null pointer somehow.

Date/Time:      2011-11-18 08:17:39.548 -0800
OS Version:     10.4.11 (Build 8S165)
Report Version: 4

Command: firefox
Path:    /Applications/TenFourFox7450.app/Contents/MacOS/firefox
Parent:  WindowServer [60]

Version: 8.0 (8.0)

PID:    630
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0   libJPEG.dylib               0x91b5db68 decode_mcu_optimized + 292
1   libJPEG.dylib               0x91b50cf0 consume_data + 376
2   libJPEG.dylib               0x91b49018 _cg_jpeg_consume_input + 240
3   XUL                         0x02213798 void 
std::__adjust_heap<__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, 
std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > 
>, int, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, 
nsRefPtr<imgCacheEntry> 
const&)>(__gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, 
std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > 
>, int, __gnu_cxx::__normal_iterator<nsRefPtr<imgCacheEntry>*, 
std::vector<nsRefPtr<imgCacheEntry>, std::allocator<nsRefPtr<imgCacheEntry> > > 
>, nsRefPtr<imgCacheEntry>, bool (*)(nsRefPtr<imgCacheEntry> const&, 
nsRefPtr<imgCacheEntry> const&)) + 62008
...

Original comment by classi...@floodgap.com on 18 Nov 2011 at 4:19

[GoogleCodeExporter]

When fed to Preview.app on the same machine, the JPEG *does* render. So this is 
definitely something we should be catching.

Original comment by classi...@floodgap.com on 18 Nov 2011 at 4:20

[GoogleCodeExporter]

>Also, 10.4 or 10.5?

My G3s run 10.4.11, the G4 PowerBook runs 10.5.8 (and 10.3.9). I don't have a 
10.4 installation for the G4 PowerBook to test with.

Original comment by chtru...@web.de on 18 Nov 2011 at 5:10

[GoogleCodeExporter]

TFF 8.0 G3 version doesn't crash when run on the G4 PowerBook with 10.5.8.

Original comment by chtru...@web.de on 18 Nov 2011 at 5:17

[GoogleCodeExporter]

Seems to be another mozilla JPEG decoding oddity - the code seems to rely on 
libjpeg reclaiming every when it's been passed a null pointer.

Might be fixed by adding an inline function jpeg_consume_input() that redirects 
to cg_jpeg_consume_input() (instead of a simple #define). I imagine that 
function should do the same as the other inline I already added.

However I currently don't have any source tree available do implement this 
myself.

Original comment by Tobias.N...@gmail.com on 19 Nov 2011 at 8:09

[GoogleCodeExporter]

The following might be worth a try:

#if(1)
LOCAL(int) inline jpeg_consume_input JPP((j_decompress_ptr cinfo))
{
  if (cinfo->src->next_input_byte == NULL) {
    if (cinfo->src->bytes_in_buffer != 0)
      cinfo->src->bytes_in_buffer = 0;
    if (! (*cinfo->src->fill_input_buffer) (cinfo))
      return 0; /* suspend */
  }
  return _cg_jpeg_consume_input(cinfo);
}
#else
#define jpeg_consume_input _cg_jpeg_consume_input
#endif

Original comment by Tobias.N...@gmail.com on 19 Nov 2011 at 8:16

[GoogleCodeExporter]

(assigning to me for completion)

That looks like it's worth a shot. I'm trying to finish up regex acceleration 
for 9 and then I will throw your code in.

Original comment by classi...@floodgap.com on 19 Nov 2011 at 3:54

[GoogleCodeExporter]

Original comment by classi...@floodgap.com on 19 Nov 2011 at 4:08

• Added labels: Milestone-NextBeta9

[GoogleCodeExporter]

Landed in 9 beta

Original comment by classi...@floodgap.com on 23 Nov 2011 at 9:13

• Changed state: Started

[GoogleCodeExporter]

Original comment by Tobias.N...@gmail.com on 23 Nov 2011 at 10:26

[GoogleCodeExporter]

Crash is repaired by the patch. Leaving open to verify no regressions.

Original comment by classi...@floodgap.com on 29 Nov 2011 at 2:36

[GoogleCodeExporter]

Confirmed, 9.0b1 doesn't crash.

Original comment by chtru...@web.de on 2 Dec 2011 at 9:18

[GoogleCodeExporter]

Marking verified

Original comment by classi...@floodgap.com on 3 Dec 2011 at 12:57

• Changed state: Verified