Back to the main page.

Bug 934 - Matlab does not shutdown properly

Status CLOSED WONTFIX
Reported 2011-09-05 12:52:00 +0200
Modified 2019-08-10 12:29:23 +0200
Product: FieldTrip
Component: realtime
Version: unspecified
Hardware: PC
Operating System: Windows
Importance: P2 major
Assigned to:
URL:
Tags:
Depends on:
Blocks:
See also:

Philip van den Broek - 2011-09-05 12:52:16 +0200

If a fieldtrip buffer server has been installed in a Matlab session running under windows (winXP), then after exiting Matlab a process keeps running in the background. This causes issues when shutting down the computer or when corresponding Matlab session was automatically launched software-wise. It can be simulated by just executing: >> ft_create_buffer(1972) followed by: >> ft_destroy_buffer This will make Matlab freeze and it can only be stopped through the Windows Task Manager.


Robert Oostenveld - 2011-09-05 16:29:49 +0200

On 5 Sep 2011, at 13:53, Philip van den Broek wrote: Ik zag zojuist dat bug 934 wellicht gerelateerd is aan de eerder gerapporteerde bug 748.


Boris Reuderink - 2012-05-16 11:20:13 +0200

I just stole this bug from Arjen since Philip asked me about it. I can replicate this bug on Windows 7, but not on Linux (mentat301). Thus, it appears to be platform specific. The mex-file that is called from Philips example is $FT/realtime/buffer/matlab/buffer.c.


Boris Reuderink - 2012-05-21 14:30:57 +0200

It appears that the cleanup function 'exitFun' in buffer.c is not even reached. The problem can be replicated by calling and clearing the mex file directly: >> buffer('tcpserver', 'init', 'localhost', 1972); >> clear; % no problem >> clear buffer; % hangs Similarly, >> clear mex; hangs. I can't find much information how mex files are cleared exactly. Apparently, th fist clear statement skips the buffer mex file. Further, the buffer function does not seem to be locked ('help mislocked').


Boris Reuderink - 2012-05-21 14:35:56 +0200

Please note that without starting a buffer server, clearing the mex does work: >> buffer('tcpserver', 'exit'); >> clear mex; % no problem


Boris Reuderink - 2012-05-30 10:40:45 +0200

Note to self: I managed to write to a file during the clear statement; apparently the registered exit function 'exitFun' is reached after all.


Boris Reuderink - 2012-05-30 10:54:57 +0200

Note to self: seems to be hanging on join statement: http://code.google.com/p/fieldtrip/source/browse/trunk/realtime/buffer/matlab/buffer.c#88


Boris Reuderink - 2012-10-17 15:12:03 +0200

*** Bug 1784 has been marked as a duplicate of this bug. ***


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

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


Robert Oostenveld - 2013-01-24 12:29:07 +0100

I changed a bunch of bugs that were assigned to fieldtrip-bugs from ASSIGNED into NEW, since nobody is now explicitly working on them.


Jan-Mathijs Schoffelen - 2014-09-11 15:45:45 +0200

Revisiting some old bugs: @Philip: is this still something that should be looked into?


Philip van den Broek - 2014-09-11 17:09:32 +0200

Yes, I would still be very happy if this issue could be solved. The issue not only occurs on systems running windows (Matlab hangs), but also on macs running OSX. Although in the latter case Matlab often (not always) crashes at the moment Matlab shuts down and clears the buffer mex file.


Arjen Stolk - 2014-11-12 16:18:04 +0100

(In reply to Philip van den Broek from comment #11) Do you happen to have a solution/implementation, or suggestion for a fix? Given that we currently do not have the resources to take up this project, I feel inclined to label this bug as a 'wont fix'. Feel free to reopen this bug in case you think otherwise.


Philip van den Broek - 2014-11-13 08:59:24 +0100

(In reply to Arjen Stolk from comment #12) Unfortunately, I do not have any suggestion for a fix. I will only opt for reopening the bug if new insights would make efforts from your side meaningful. Anyway thanks for taken efforts thus far.


Robert Oostenveld - 2014-11-13 09:25:29 +0100

(In reply to Philip van den Broek from comment #11) None of the people of the FieldTrip team at the DCCN can afford their time working on this. The only solution that I see is that someone outside the DCCN fixes it.


Robert Oostenveld - 2019-08-10 12:29:23 +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 https://github.com/fieldtrip/fieldtrip/issues.