MRXS 2.2 - test failures

[Benjamin Gilbert]

On 11/13/2012 04:12 AM, Agelos Pappas wrote:
> in the first image you can see what the slide looks like zoomed out. In
> the second, I zoomed one step in and the application crashed reporting
> an access violation in openslide_read_region.

It sounds like the crash dump is our best lead at the moment.  Is there 
anything interesting in it?  Can you localize this to the offending line 
of code?

(Can Windows debuggers read mingw's debugging symbols?  If not, you can 
try running gdb in Cygwin.)

> I didn't notice any corrupted images or crashes using the java viewer
> under windows. Is it multithreaded?

No.

> I wrote a simple desktop application that
> spawns N threads, each of which instantiates a single openslide_t, all
> to a specific slide file.
> Every thread then walks from the top zoom level to the bottom reading
> 256x256 tiles. If N equals to the number of CPU cores your system has,
> so that the app runs quicker, the application crashes almost immediately.
> If I perform a lock in openslide_read_region calls, the application runs
> fine, but slower since tiles are read in series.

So each openslide_t is only ever touched by a single thread? 
openslide_t handles do not share any resources, so it's probably not a 
thread-safety issue within OpenSlide.  But it could be caused by 
OpenSlide corrupting memory.

> I do know that we
> only encountered this when we switched to the latest OpenSlide binaries.

Interesting.  You could try using "git bisect" to find the OpenSlide 
commit that introduced the problem.  That will be painful, but if we run 
out of other ideas...

> FYI I'd like to let you know that I cross compiled OpenSlide using
> libjpeg and the problems persist.

OK, so the Valgrind warnings are probably unrelated.

--Benjamin Gilbert