New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
input_char after close_in crashes ocaml (msvc runtime) #4887
Comments
Comment author: @ygrek Oops, the uploaded file has _set_invalid_parameter_handler already uncommented. |
Comment author: @xavierleroy Two years after, I'm still confused about what needs to be done: play with _set_invalid_parameter_handler? with _CtrSetReportMode? with both? should we #ifdef the code so that it remains compatible with earlier versions of VS? or not bother? A sample patch that's been tested would be very much appreciated. Thanks. |
Comment author: @ygrek IIUC _CrtSetReportMode has nothing to do with this bug. We should only _set_invalid_parameter_handler to not crash process. I will try to prepare the patch. |
Comment author: @xavierleroy Dear "ygrek", Any progress on a patch? At any rate, I'm unassigning myself from this issue, hoping that others will be more motivated to work on it. |
Comment author: @ygrek Sorry, I am not using windows for development anymore, so I am not very likely to provide the tested patch.. |
Comment author: Christoph Bauer I have a similar problem, when writing to a broken pipe. With the ocaml-mingw My solution is to install an empty invalid_parameter_handler. Then it is ok again. BTW, to get a stack trace in Windows I added in config/Makefile to the compiler flags (BYTECCCOMPOPTS, DLLCCCOMPOPTS, NATIVECCCOMPOPTS) a /Zd and to the link flags (MKDLL, MKEXE, MKMAINDLL) #ifdef _MSC_VER void myInvalidParameterHandler(const wchar_t* expression, /* empty */ } CAMLprim _set_invalid_parameter_handler(myInvalidParameterHandler); #endif |
Comment author: @alainfrisch Christophe: thanks for the information. Would you like to propose a patch? |
Comment author: Christoph Bauer A patch against trunk is attached. It is tested with MSVC 2010. |
Comment author: @alainfrisch Thanks! I've committed your patch to the trunk (r13257), with the following modification: caml_install_invalid_parameter_handler is also called from caml_startup_code in byterun/startup.c (i.e. when the main program is linked with -output-obj in bytecode). It is not very nice to set the global handler if we embed the OCaml code in a larger native application, but this is probably good enough for now (and this is what happens in native code). If someone needs to disable this behavior for a specific application, we can always introduce later some global flags checked by caml_startup_code. (Also tested with VS 2008, 32-bit.) |
Original bug ID: 4887
Reporter: @ygrek
Assigned to: @alainfrisch
Status: closed (set by @xavierleroy on 2015-12-11T18:18:26Z)
Resolution: fixed
Priority: normal
Severity: crash
Version: 3.11.0
Fixed in version: 4.01.0+dev
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @protz "Christoph Bauer"
Bug description
Problem is specific to msvc runtime.
Create the file 1.txt and run (toplevel or compiled - doesn't matter) :
let _ = let ch = open_in "1.txt" in close_in ch; input_char ch
Additional information
fd is closed and assigned -1, after that read(-1,...) results in CRT invoking invalid_parameter_handler which takes down the whole process by default.
A simple C program that shows this behavior and a fix is attached. Uncomment line 30 to call _set_invalid_parameter_handler and disable default handler -- _read will return error and program continues as expected.
Looking at MSDN it appears this behaviour was introduced in VS80..
See http://msdn.microsoft.com/en-us/library/a9yf33zb(VS.80).aspx and
http://msdn.microsoft.com/en-us/library/wyssk1bs(VS.80).aspx and http://msdn.microsoft.com/en-us/library/wyssk1bs(VS.71).aspx
File attachments
The text was updated successfully, but these errors were encountered: