[erlang-bugs] case_clause in io:put_chars during common test run

Nico Kruber <>
Wed Feb 27 16:13:02 CET 2013

Hi Siri,

On Wednesday 27 Feb 2013 12:32:12 Siri Hansen wrote:
> Hi Nico - nice to see that you found the problem.
> There have been some changes to the logging mechanism in test_server,
> mainly to ensure that output is sent to the correct log when running
> parallel test cases. The unexpected I/O log is also added - it will be used
> if it can not be decided which test case a particular printout is related
> to. However, I don't think any of these changes could cause the problem you
> see.

I agree - it's rather a change in the io module now starting async processes

> The process which is killed is probably the file descriptor process for the
> html log for end_per_suite (as you kill processes in the post_end_per_suite
> hook function), and this log has always been opened at the same time as
> end_per_suite - i.e. way after you collect your original set of processes.

yes - the original set of processes is collected in the init_per_suite hook.

> I would rather think that there is something in your filtering that does no
> longer work - maybe the timing has changed a bit so you more often(?) get
> current function of the file descriptor process to be something other than
> file_io_server... ?? I'm just guessing now...

the only exceptions I needed so far were:
                     not (InitCall =:= {test_server_sup, timetrap, 3} andalso
                              CurFun =:= {test_server_sup, timetrap, 3}),
                     not (InitCall =:= {test_server_sup, timetrap, 2} andalso
                              CurFun =:= {test_server_sup, timetrap, 2}),
                     not (InitCall =:= {test_server_gl, init, 1}),
> Anyway - I think the way to filter out such processes would be to check if
> it is a file descriptor and possibly check if the file name starts with
> your test suite name (file:pid2name/2). At least that's the only thing I
> can come up with right now...

that's probably a good idea - for now the check for the current_function works 
(also based on the code I looked at in the io and prim_file modules) but if I 
hit this error again, I'll probably try this approach - thanks.

> Good luck!
> /siri
> 2013/2/26 Nico Kruber <>
> > Hi Siri,
> > Thank you for looking into this but, I just found the code responsible for
> > the
> > error - on our side:
> > 
> > At the end of each test suite (via a common test hook) we kill all
> > processes
> > that have not been running before the suite was started (to make sure that
> > previous test suites don't influence new ones). This includes processes
> > spawned without linking to the originating process - the rest is already
> > killed by common test.
> > 
> > There are some exceptions and apparently something changed and we killed
> > too
> > many processes. In this case it was the following:
> > initial_call:             {erlang,apply,2},
> > current_function:  {prim_file,drv_get_response,1}
> > 
> > There is no safe way to filter that process out (based on current_function
> > or
> > any other process_info I'm aware of) and I'd rather use some common test
> > functionality isolating test suites but so far I'm not aware of any...
> > -> this would be a useful extension to common test though
> > 
> > 
> > Nico

More information about the erlang-bugs mailing list