AFP beta 1.7.1.140 HSL crash

[Richard Liu]

Well, I thought the HSL crash had been fixed in 1.7.1.140 (see 

), but it just bit me again -- twice.  Here are the logs:  AFP 1.7.1.140 HSL crash.zip .  Curiously, it takes a rather long time for the system to catch the crash and/or generate the log.  Could this be a by-product of the fix?

[Chris B]

Hi Richard,

I assume @Andy Somerfield will see this thread at some point and take a peek at the new crash reports for you. 

[Richard Liu]

Another HSL crash.  This time, I was only working on the document that caused the crash (i.e., there were no tabbed windows open in AFP), and I had restarted AFP before opening the raw file and developing it.  Here is the log:  AFP 1.7.1.140 HSL crash #3.zip

[Richard Liu]

Several more crashes with the same document, always when I try to insert an HSL adjustment layer.  I will omit the logs unless instructed to send them.

[Andy Somerfield]

Hi again Richard,

Thanks for the extra reports - a different issue this time, but one which I am aware of and will make every effort to fix before the GM tomorrow..

As an aside, here is a quick way to interpret the crash reports:

1.) Figure out which thread number crashed - should be near the top of the file, zero in this case - eg:

Crashed Thread:        0

2.) Scroll down the crash report to find that thread number - eg.

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread

3.) Look at the lines immediately below - in your case:

0   liblibpersona.dylib               0x0000000114872f3a HSLRangeControlView::Draw(Kernel::Counted<Raster::Buffer<Raster::Red8, Raster::Green8, Raster::Blue8, Raster::Alpha8, Raster::X5> >) + 3786

This is a bug with the drawing the HSL range control - your previous reports crashes somewhere inside Intel_CHAL_Driver::GetWorkSize() - a GPU problem.

Thanks again for your help - hopefully this will all be sorted for you in the GM build tomorrow

Andy.