Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004887OCamlOCaml generalpublic2009-10-05 12:062013-01-17 10:05
Reporterygrek 
Assigned Tofrisch 
PrioritynormalSeveritycrashReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version3.11.0 
Target VersionFixed in Version4.01.0+dev 
Summary0004887: input_char after close_in crashes ocaml (msvc runtime)
DescriptionProblem 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 Informationfd 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 [^]
TagsNo tags attached.
Attached Filesc file icon q.c [^] (1,011 bytes) 2009-10-05 12:06 [Show Content]
patch file icon ocaml_trunk_invalid_parameter_handler.patch [^] (2,148 bytes) 2013-01-16 14:47 [Show Content]

- Relationships

-  Notes
(0005128)
ygrek (reporter)
2009-10-05 12:08

Oops, the uploaded file has _set_invalid_parameter_handler already uncommented.
(0006385)
xleroy (administrator)
2011-12-19 12:05

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.
(0006404)
ygrek (reporter)
2011-12-20 10:57

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.
(0007639)
xleroy (administrator)
2012-07-04 20:04

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.
(0008030)
ygrek (reporter)
2012-09-07 10:32

Sorry, I am not using windows for development anymore, so I am not very likely to provide the tested patch..
(0008597)
Christoph Bauer (reporter)
2012-12-12 12:33

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
(0008755)
frisch (developer)
2013-01-15 14:26

Christophe: thanks for the information. Would you like to propose a patch?
(0008761)
Christoph Bauer (reporter)
2013-01-16 14:49

A patch against trunk is attached. It is tested with MSVC 2010.
(0008771)
frisch (developer)
2013-01-17 10:04
edited on: 2013-01-17 10:06

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


- Issue History
Date Modified Username Field Change
2009-10-05 12:06 ygrek New Issue
2009-10-05 12:06 ygrek File Added: q.c
2009-10-05 12:08 ygrek Note Added: 0005128
2009-12-22 20:20 xleroy Status new => assigned
2009-12-22 20:20 xleroy Assigned To => xleroy
2011-12-19 12:05 xleroy Note Added: 0006385
2011-12-19 12:05 xleroy Status assigned => feedback
2011-12-20 10:57 ygrek Note Added: 0006404
2011-12-20 10:57 ygrek Status feedback => assigned
2012-07-04 17:13 doligez Target Version => 4.00.0+dev
2012-07-04 20:04 xleroy Note Added: 0007639
2012-07-04 20:04 xleroy Assigned To xleroy =>
2012-07-04 20:04 xleroy Status assigned => acknowledged
2012-07-06 16:18 doligez Target Version 4.00.0+dev => 4.01.0+dev
2012-07-31 13:36 doligez Target Version 4.01.0+dev => 4.00.1+dev
2012-09-06 19:12 frisch Target Version 4.00.1+dev => 4.00.2+dev
2012-09-07 10:32 ygrek Note Added: 0008030
2012-12-12 12:33 Christoph Bauer Note Added: 0008597
2013-01-15 14:26 frisch Note Added: 0008755
2013-01-16 14:47 Christoph Bauer File Added: ocaml_trunk_invalid_parameter_handler.patch
2013-01-16 14:49 Christoph Bauer Note Added: 0008761
2013-01-17 08:38 frisch Assigned To => frisch
2013-01-17 08:38 frisch Status acknowledged => assigned
2013-01-17 10:04 frisch Note Added: 0008771
2013-01-17 10:05 frisch Status assigned => resolved
2013-01-17 10:05 frisch Resolution open => fixed
2013-01-17 10:05 frisch Fixed in Version => 4.01.0+dev
2013-01-17 10:05 frisch Target Version 4.00.2+dev =>
2013-01-17 10:06 frisch Note Edited: 0008771 View Revisions


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker