Ticket #1 (new defect)

Opened 6 years ago

Last modified 5 years ago

My UArr code looks like it's reading uninitialized memory?

Reported by: pumpkingod@… Owned by: somebody
Priority: minor Milestone:
Component: component1 Version:
Keywords: Cc: pumpkingod@…


I'm parsing in a reasonably large data file (I've included a smaller one that still exhibits the problem) in CSV format, replacing all NaNs? with 0, and then proceeding to calculate a sliding window mean over the columns of the data. The data has no NaNs? in it, so there's no reason for any of the means to be NaN/e308, and definitely no reason to see changes between runs of the program (unless I'm doing something very wrong!).

I compile with ghc -O2 --make -o minimal minimal.hs and run with ./minimal. The data files used are in data, and the program relies on current path so run it from the parent folder of data.

See the two_runs file for an example of what I get from two successive runs of the program, with nothing else in between. The data files don't ever change.

I'm compiling on GHC 6.10.1 (the 32-bit package from haskell.org) on Mac OS 10.5.

My code and data are at http://pumpkinpat.ch/uvector_bug.tbz .

Change History

Changed 5 years ago by pumpkingod@…

  • priority changed from major to minor

I tracked this down to issues in my understanding of zipU and friends, where zipU happily reads past the end of the second array if the first is longer. lengthU on the resulting array will catch this is the safe flag is on. It seems like reasonable behavior, it just needs to be outlined in the documentation (which I'm doing).

Note: See TracTickets for help on using tickets.