| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixed sc-bad-write once again...
It seems that the BSS segment got larger than one page for some reason,
which caused the test to be useless as the boundary to nonmapped memory
were not located where the test thought. Now, it uses some linker script
magic to define the symbol _bss_end, the address of which is after the
end of the bss segment. This seems to be a fool-proof way of detecting
where the real boundary to unmapped memory is.
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
See merge request !7
|
| |/
|
|
|
|
|
|
|
|
|
| |
It seems that the BSS segment got larger than one page for some reason,
which caused the test to be useless as the boundary to nonmapped memory
were not located where the test thought. Now, it uses some linker script
magic to define the symbol _bss_end, the address of which is after the
end of the bss segment. This seems to be a fool-proof way of detecting
where the real boundary to unmapped memory is.
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
|
| |\
| |
| |
| |
| |
| |
| | |
Fixed sc-bad-write test to be more precise.
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
See merge request !6
|
| |/
|
|
| |
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
|
| |\
| |
| |
| |
| |
| |
| | |
Fix up exec-corrupt to accept exit(-1) anywhere, make sc-bad-write reserve space…
… for 3 parameters instead of 4
See merge request !5
|
| |/
|
|
| |
space for 3 parameters instead of 4
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix for possible bug in exec-missing.
The test userprog/exec-missing verifies that exec() returns -1 when
starting a process for which the binary is not found. Since the failure
of load() is discovered after a new process has been created, the output
'no-such-file: exit(-1)' will be visible in the output. The problem is
that we do not know when this happens with respect to the thread calling
exec(). Due to how the tests are designed, the time when 'no-such-file'
terminates is important. Some of the cases were listed as acceptable
outputs, but I found some acceptable outputs missing from there, namely
if 'no-such-file' for some reason takes quite some time terminating, or
even terminates after the 'exec-missing' process exits. As there is no
synchronization between these processes (nor can it be), we do not know
which one terminates first.
Effectively, I added the following possible outputs to the test, as I
find them reasonable outcomes of a correct implementation (in very
unfortunate circumstances, or when printing a lot in process_cleanup):
```
(exec-missing) begin
load: no-such-file: open failed
(exec-missing) exec("no-such-file"): -1
(exec-missing) end
no-such-file: exit(-1)
exec-missing: exit(0)
```
```
(exec-missing) begin
load: no-such-file: open failed
(exec-missing) exec("no-such-file"): -1
(exec-missing) end
exec-missing: exit(0)
no-such-file: exit(-1)
```
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
See merge request !4
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The test userprog/exec-missing verifies that exec() returns -1 when
starting a process for which the binary is not found. Since the failure
of load() is discovered after a new process has been created, the output
'no-such-file: exit(-1)' will be visible in the output. The problem is
that we do not know when this happens with respect to the thread calling
exec(). Due to how the tests are designed, the time when 'no-such-file'
terminates is important. Some of the cases were listed as acceptable
outputs, but I found some acceptable outputs missing from there, namely
if 'no-such-file' for some reason takes quite some time terminating, or
even terminates after the 'exec-missing' process exits. As there is no
synchronization between these processes (nor can it be), we do not know
which one terminates first.
Effectively, I added the following possible outputs to the test, as I
find them reasonable outcomes of a correct implementation (in very
unfortunate circumstances, or when printing a lot in process_cleanup):
(exec-missing) begin
load: no-such-file: open failed
(exec-missing) exec("no-such-file"): -1
(exec-missing) end
no-such-file: exit(-1)
exec-missing: exit(0)
(exec-missing) begin
load: no-such-file: open failed
(exec-missing) exec("no-such-file"): -1
(exec-missing) end
exec-missing: exit(0)
no-such-file: exit(-1)
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | | |
should expect when running it
|
| |\ \ \ |
|
| | | |/
| |/|
| | |
| | | |
Signed-off-by: Filip Strömbäck <filip.stromback@liu.se>
|
| |/ / |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
