MinGW blosc_decompress_ctx decompression exception with -O3 about c-blosc HOT 18 CLOSED

Probably related to #82 , I also have the suite benchmark hanging

Also, x86 doesn't work at all with AccessViolationException on the first compression call. I wonder if it is expected that MinGW build should work out of the box on x86 smoothly?

from c-blosc.

After some further reading this is obviously related to #74, my MinGW gcc version is 4.9.2. But the test fails even with the default BloscLZ compressor.

from c-blosc.

That's strange. At least on Linux, the only compressor that was affected was LZ4, but perhaps MinGW is uncovering other side effects by GCC 4.9 series :(. What's the version of the c-blosc library that you are testing? 1.5.2 was known to work with GCC 4.9.1.

from c-blosc.

@FrancescAlted I am using master head as of yesterday

from c-blosc.

Just recompiled 1.5.2 - same thing, with O3 and number of threads above 1 blosc_decompress_ctx throws AccessViolationException

from c-blosc.

I was incorrect, all modes -O0..-O3 throw an exception with multiple decompression threads, -O3 throws AccessViolation, -O0 throws SEHException. I need to review the source and my interop code (if they match) and cross-compile on Linux for Windows with MinGW to be somewhat sure it is not my code.

What about x86? Is the code supposed to work without additional flags or anything when compiled with MinGW (i.e. was it tested by someone)? If yes then my build is likely broken, if no - then there is probably some issue with Windows/MinGW.

Single threaded is quite fast - faster than any other alternative I had before I found this fascinating library! My main concern is stability though.

from c-blosc.

Can you try with some pre 1.5 version?

Enviat des del meu iPhone

El 15/01/2015, a les 19:47, Victor Baybekov [email protected] va escriure:

I was incorrect, all modes -O0..-O3 throw an exception with multiple decompression threads, -O3 throws AccessViolation, -O0 throws SEHException. I need to review the source and my interop code (if they match) and cross-compile on Linux for Windows with MinGW to be somewhat sure it is not my code.

What about x86? Is the code supposed to work without additional flags or anything when compiled with MinGW (i.e. was it tested by someone)? If yes then my build is likely broken, if no - then there is probably some issue with Windows/MinGW.

Single threaded is quite fast - faster than any other alternative I had before I have found this fascinating library! My main concern is stability though.

—
Reply to this email directly or view it on GitHub.

from c-blosc.

same with the first commit where the _ctx functions were introduced. ff6ca8e

I haven't tried older functions which require init(). will come back after double check if my build is broken or not. The simplest way is to write the same test in pure C and debug.

from c-blosc.

When I set this line to two threads the test_basics.exe crashes, with 1 thread it is OK. My experience with C and tooling is not enough yet to debug it.

from c-blosc.

Good to know, thanks. Yeah, I strongly suspect that we introduced some multithreading glitch during the big revamp for 1.5 series.

from c-blosc.

Without digging into it too much but judiging from the recent issues we have been seeing with bcolz, that is my gut feeling also.

from c-blosc.

@buybackoff Can you check whether this issue is fixed by #87?

from c-blosc.

@jack-pappas together with the latest commit it doesn't help. Same crash after a couple of thousands iterations of compress/decompress calls via P/Invoke to _ctx versions on 2+ threads.

from c-blosc.

Ah, that's unfortunate. The change in #87 seems to fix the hanging issue in the benchmark tool I reported in #82.

Btw, in the C# P/Invoke signature you provided above for blosc_decompress_ctx -- I think the type of the numinternalthreads parameter should be an int or uint, not IntPtr.

from c-blosc.

Thanks, fixed that. As long as I do not box integers and use a pointer to boxed int, but use just new IntPtr(2) could that matter?

BTW, I have realized that Blosc blocksize blocksize = L1 * 4; with clevel 9 blocksize *= 2 is 16-32 times larger than my typical data (8-16Kb), since I cut large data sets into chunks myself before calling Blosc. So the issue became irrelevant from practical point of view as I do not need 2+ threads. But the error persists when data is larger than a single block.

from c-blosc.

With MinGW, x86 version crashed even with single thread. I recompiled the library with CMake+VS12, now x86 works fine with one thread, but the crash with 2+ threads remains with the same behavior.

from c-blosc.

Version 1.7 (compiled with CMake + VS2015RC) works great without exceptions, both x86 and x64

from c-blosc.

Cool. Thanks for the feedback!

from c-blosc.