Back to the main page.

Bug 1754 - new compiled nanXXX functions don't work

Reported 2012-10-01 11:09:00 +0200
Modified 2019-08-10 11:55:39 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P3 blocker
Assigned to:
Depends on:
See also:

Jan-Mathijs Schoffelen - 2012-10-01 11:09:54 +0200

1. nanmean gives a segmentation error using matlab2010b on mentat309 2. nanmean produces nonsense using matlab2011b on mentat309

Jan-Mathijs Schoffelen - 2012-10-01 11:12:16 +0200

>> !vim test_bug1754.m >> !svn add test_bug1754* A test_bug1754.m A (bin) test_bug1754.mat >> !svn commit test_bug1754* Adding test_bug1754.m Adding (bin) test_bug1754.mat Transmitting file data .. Committed revision 6607.

Boris Reuderink - 2012-10-01 12:36:34 +0200

Ok, I'll investigate.

Boris Reuderink - 2012-10-01 12:49:14 +0200

Created attachment 332 Stacktrace produced by testscript run with matlab2010b.

Boris Reuderink - 2012-10-01 12:52:27 +0200

1. I can reproduce the crash (attached stacktrace) with MATLAB 2010b. 2. With matlab2011b, I also get a crash, with a stacktrace. @JM: what did you get?

Jan-Mathijs Schoffelen - 2012-10-01 12:54:58 +0200

infs and -infs all over the place. trying to reproduce just now, I also get a segmentation violation, so no infs anymore.

Boris Reuderink - 2012-10-01 12:57:41 +0200

WIth MATLAB 2009b it also crashes. But, it can run $FT/src/test_nanstat.m just fine. Thus, there is a difference between what the unit-tests check, and what test_bug1754 does. Probably the INFs and NANs were just signs memory corruption, without a full segmentation fault?

Boris Reuderink - 2012-10-01 13:02:35 +0200

On Windows with MATLAB 2010b, it does not crash.

Jan-Mathijs Schoffelen - 2012-10-01 13:10:24 +0200

I don't care about windows

Jan-Mathijs Schoffelen - 2012-10-01 13:17:14 +0200

the reason I thought it had to do with nanmean (in test_bug1754), is that if I replace the call to nanmean in ft_freqbaseline into a call to mean, the issue does not occur

Boris Reuderink - 2012-10-01 13:55:43 +0200

Met with JM in meatspace, and the output on Windows is also corrupted.

Boris Reuderink - 2012-10-01 14:58:36 +0200

I was able to more or less isolate the issue: it seems to occur when handling the right-most dimension (i.e. the one furthest apart in memory). Debugging was complicated due to mixing paths, (private) dirs with mex files, and non-informative crashes.

Boris Reuderink - 2012-10-01 15:21:16 +0200

Note to self: this might have something to do with mxGetNumberOfDimensions() secretly not counting leading singleton dimensions.

Boris Reuderink - 2012-10-01 15:23:52 +0200

(In reply to comment #12): correction *trailing* singleton dimensions.

Boris Reuderink - 2012-10-01 15:35:25 +0200

Okay, now I understand this problem, and I have made a local fix. TODO: - clean up changes, commit fix. - recompile nan* on all major platforms (ugh :/).

Boris Reuderink - 2012-10-01 15:47:35 +0200

Commited fix in SVN revision 6610.

Boris Reuderink - 2012-10-01 20:28:43 +0200

Compiled mex files for Windows, Linux & OSX, see revisions r6616--r6621. These problems were introduced in revision r6589 (Friday 2012-09-28, 13:00). Probably we should notify users that downloaded FieldTrip between September 28th and October 2nd.

Boris Reuderink - 2012-10-02 10:10:27 +0200

Marking this bug as RESOLVED:FIXED. TODO: Notify users if not reopened this week.

Boris Reuderink - 2012-11-02 13:29:51 +0100

I am no longer working on FieldTrip. Hence, I donate all my bugs to the joint development user.

Robert Oostenveld - 2019-08-10 11:51:41 +0200

This closes a whole series of bugs that have been resolved (either FIXED/WONTFIX/INVALID) for quite some time. If you disagree, please file a new issue describing the issue on

Robert Oostenveld - 2019-08-10 11:55:39 +0200

This closes a whole series of bugs that have been resolved (either FIXED/WONTFIX/INVALID) for quite some time. If you disagree, please file a new issue describing the issue on