The function genericGetVectorWith should not to be inlined.

[tangboyun]

I 've defined a data like this:

getBasicData :: Int -> Get BasicData
getBasicData n = BasicData
             <$> genericGetVectorWith (return n) getInt32le
             <*> genericGetVectorWith (return n) getInt32le
             <*> genericGetVectorWith (return n) getInt32le
             <*> genericGetVectorWith (return n) getInt32le
             <*> genericGetVectorWith (return n) getFloatle
             <*> genericGetVectorWith (return n) getWord8

While trying to print the data, it outputs:

[4850337,4850337,4850337,4850344,4850344,4850344,4850344,4850344,4850344,4850344]
[4850337,4850337,4850337,4850344,4850344,4850344,4850344,4850344,4850344,4850344]
[4850337,4850337,4850337,4850344,4850344,4850344,4850344,4850344,4850344,4850344]
[4850337,4850337,4850337,4850344,4850344,4850344,4850344,4850344,4850344,4850344]
[0.8,0.8,0.8,0.8,0.8,0.8,0.8,0.8,0.8,0.8]
[2,3,1,2,3,3,3,3,3,1]

It should be:

[-140392093,-140392093,-140392093,-140392093,-140392093,-140392093,-140392093,-140392093,-140392093,-140392093]
[316,2999,6687,0,278,1904,4098,5799,7449,9230]
[2956,6642,8567,232,1861,4055,5755,7407,9180,9340]
[4850337,4850337,4850337,4850344,4850344,4850344,4850344,4850344,4850344,4850344]
[0.8,0.8,0.8,0.8,0.8,0.8,0.8,0.8,0.8,0.8]
[2,3,1,2,3,3,3,3,3,1]

When mark this fuction as NOINLINE or set ghc option -fno-cse, the bug disappeared.

[RyanGlScott]

Can you post the full code that you're using? This sounds like a GHC bug, as the presence of an INLINE pragma shouldn't affect the semantics of a program like this.

[bgamari]

@tangboyun, can you confirm that you are using the most recent release?

@RyanGlScott, it's plausible that this is a real bug in this package as there are some nasty unsafePerformIOs in genericGetVectorWith. Unfortunately binary doesn't have proper support for side-effecting deserialisation so these aren't really possible to avoid.

Looking more carefully at genericGetVectorWith I can see that the INLINE pragma is indeed suspicious although I can't immediately see how it might go wrong.

[bgamari]

@tangboyun could you provide a reproducer for this?

[tangboyun]

The source code to reproduce the problem: vectorInsBug-0.1.0.0.tar.gz
The input can be dowloaded here : https://downloads.pacbcloud.com/public/dataset/RC0_1cell_2017/m54086_170204_081430.subreads.bam.pbi

To reproduce the bug:
stack build && release/vectorInsBug m54086_170204_081430.subreads.bam.pbi

To fix the bug:

• stack build --ghc-options '-fno-cse' && release/vectorInsBug m54086_170204_081430.subreads.bam.pbi
• OR, change the INLINE pragma on the 'genericGetVectorWith' function to NOINLINE

[RyanGlScott]

Ah, I had no idea that genericGetVectorWith was using unsafePerformIO until @bgamari mentioned it. That might indeed explain why different optimization levels produce different runtime behavior.

Also, thanks for offering a relatively self-contained example of how to trigger the bug, @tangboyun. I'm able to reproduce the issue with this.

[0xd34df00d]

Just got bitten by this issue as well.

How do you reckon changing the implementation of genericGetVectorWith from the current one (with unsafePerformIO) to, say, using Vector's replicateM? I did this in my code, and I wasn't able to measure any significant performance difference (although this is not a hot path and I didn't put too much effort into my measurements).