I shall look in to this one. It's either a sloppy teardown on the part of the test (in which case I'll just delete it) or it indicates a failure somewhere in the process creator logic. The latter is something worth checking for.
OH! Duh. Okay. This is another case of excessive kernel paranoia. What's going on is that one of the test cases is performing a bad memory reference -- in this case probably after returning from main(). Since the program has no keeper, it's causing a segmentation fault. As a developer-oriented debugging feature, the kernel is reporting that a segment fault has been taken when there is no defined keeper for the bad program.
This should not be happening in the test case, and I will look in to it.
Second, this should never be seen by the user. Keep in mind that the
current DEFAULT configuration is a copy of the DEVEL configuration, while
the user will generally run a copy of the NDEBUG configuration. Under the
DEVEL configuration, certain "suspicious" actions that are actually
"correct" from the kernel's perspective are nonetheless flagged so that I
can observe them. This particular diagnostic is one that I ifdef in and out
when I am debugging things. What we are really seeing is an example of the
kernel trying to help cover for the fact that I don't have a user-mode
debugger written yet.
The reason I did not see this one myself is that I invariably run the perf/ benchmarks using the SMALL kernel, which doesn't perform this check and whose kernel therefore doesn't gripe about it.
shap
Bengt Kleberg <bengt@softwell.se> on 02/16/99 05:19:51 AM
To: eros-port@eros.cis.upenn.edu
cc: (bcc: Jonathan S Shapiro/Watson/IBM)
Subject: eros-0.8.1, tests/perf/lat_pipe
probably only error in exit code.
lat_pipe -- 1000 iterations
pipe: writer closes
InvokeMyKeeper(): thread takes seg flt with no keeper
Current thread 0x002131b0 (running) ctxt 0x00205920 (user)
rsrv=0x001fe300 uobj 0x00000018 0x0001100000000000
Stopped at 0x00105854 Debugger(void)+4 [db_interface.cxx:262]" movl
%ebp,%esp