Skip to content
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

Closed
vicuna opened this issue Oct 5, 2009 · 9 comments
Closed

input_char after close_in crashes ocaml (msvc runtime) #4887

vicuna opened this issue Oct 5, 2009 · 9 comments
Assignees
Labels

Comments

@vicuna
Copy link

@vicuna vicuna commented Oct 5, 2009

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

@vicuna
Copy link
Author

@vicuna vicuna commented Oct 5, 2009

Comment author: @ygrek

Oops, the uploaded file has _set_invalid_parameter_handler already uncommented.

@vicuna
Copy link
Author

@vicuna vicuna commented Dec 19, 2011

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.

@vicuna
Copy link
Author

@vicuna vicuna commented Dec 20, 2011

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.

@vicuna
Copy link
Author

@vicuna vicuna commented Jul 4, 2012

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.

@vicuna
Copy link
Author

@vicuna vicuna commented Sep 7, 2012

Comment author: @ygrek

Sorry, I am not using windows for development anymore, so I am not very likely to provide the tested patch..

@vicuna
Copy link
Author

@vicuna vicuna commented Dec 12, 2012

Comment author: Christoph Bauer

I have a similar problem, when writing to a broken pipe. With the ocaml-mingw
it worked for a long time.

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)
-link /debug -link /opt:ref -link /opt:icf
Then the OCaml compiler produces also a .pdb file for an executable.

#ifdef _MSC_VER

void myInvalidParameterHandler(const wchar_t* expression,
const wchar_t* function,
const wchar_t* file,
unsigned int line,
uintptr_t pReserved)
{

/* empty */

}

CAMLprim
value ml_set_invalid_parameter_handler(value handler)
{

_set_invalid_parameter_handler(myInvalidParameterHandler);
}

#endif

@vicuna
Copy link
Author

@vicuna vicuna commented Jan 15, 2013

Comment author: @alainfrisch

Christophe: thanks for the information. Would you like to propose a patch?

@vicuna
Copy link
Author

@vicuna vicuna commented Jan 16, 2013

Comment author: Christoph Bauer

A patch against trunk is attached. It is tested with MSVC 2010.

@vicuna
Copy link
Author

@vicuna vicuna commented Jan 17, 2013

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants