[NSWI004] How to cause segmentation fault.

[Vojtech Horky]

Hello,

originally we planned to introduce these functions in the next 
assignment but you can use them even now. panic() unconditionally halts 
your kernel with an error message, panic_if() halts the execution only 
if given condition evaluates to true.

Unlike assertions, these work regardless of debug/release mode. They are 
expected to be used when things cannot fail (e.g. you need to kmalloc() 
memory for system threads or similar).

Perhaps, you can use them here as well.

On the other hand, from the description I believe assert is better and 
perhaps rewriting it to

assert(claim_block_free((uintptr_t)header, header->size) != NULL);

would not hurt the readability (not sure whether you can remove the 
typecast) and would not introduce an unused variable.

For panic and panic_if, merge, please, with upstream repository.

Hope this helps,
- VH



Dne 30. 10. 20 v 20:39 Tomáš Kubíček napsal(a):
> You can maybe write your own assert which calls the predefined assert 
> when compiled with KERNEL_DEBUG flag, and otherwise casts it to void, to 
> avoid the unused error
> 
> On Fri, 30 Oct 2020 at 19:57, Jura Pelc <jirik.pelc1998 at gmail.com 
> <mailto:jirik.pelc1998 at gmail.com>> wrote:
> 
>     I am sorry to reopen the closed questions but assert does not suit
>     my problem.
>     following code is compilable when debugging, but is incompilable
>     during test run because of unused variable `free_block`:
>     ```c
>          freelist_item_t* free_block =
>     claim_block_free((uintptr_t)header, header->size);
>          assert(free_block != NULL);
>     ```
> 
>     ```shell
>     src/mm/heap.c:323:22: error: unused variable 'free_block'
>     [-Werror=unused-variable]
>        323 |     freelist_item_t* free_block =
>     claim_block_free((uintptr_t)header, header->size);
>            |
>     ```
> 
>     So basically I need the equivalent of `assert` but for both debug
>     and test runtime.
> 
>     pá 30. 10. 2020 v 19:12 odesílatel Petr Tuma
>     <petr.tuma at d3s.mff.cuni.cz <mailto:petr.tuma at d3s.mff.cuni.cz>> napsal:
> 
>         Hi,
> 
>         I guess your point is how to do an equivalent of an `assert`
>         statement (that is, announce a fatal error and stop the
>         execution) ? For that, there already is an `assert` macro in
>         `debug.h` ... or did you have something else in mind ?
> 
>         Petr
> 
> 
>         On 30/10/2020 18:55, Jura Pelc wrote:
>          > Hello,
>          >
>          > I am working on the implementation of free and I come across
>         a conflict between me as a C# programer and kernel C code.
>          > ```c
>          > if((uintptr_t)ptr < heap_begin || (uintptr_t)ptr > heap_end)
>          > {
>          >      //TODO: segmentation fault
>          >      return;
>          > }
>          > ```
>          > I want to safely determine that the user is dum and trying to
>         free some unknown memory.
>          > For this, I can see some kind of range check for free and
>         "throwing" segmentation fault as interop.
>          > I was thinking about
>         https://www.tutorialspoint.com/c_standard_library/c_function_raise.htm
>         <https://www.tutorialspoint.com/c_standard_library/c_function_raise.htm>,
>         but I did not found this is the kernel.
>          >
>          > So my question is, how to raise segmentation fault during
>         free safely?
>          >
>          > --
>          >
>          > S pozdravem Jiří Pelc
>          > Matematicko-fyzikální fakulta
>          > Univerzita Karlova
>          >
>          > _______________________________________________
>          > NSWI004 mailing list
>          > NSWI004 at d3s.mff.cuni.cz <mailto:NSWI004 at d3s.mff.cuni.cz>
>          > https://d3s.mff.cuni.cz/mailman/listinfo/nswi004
>          >
> 
> 
> 
>     -- 
> 
>     S pozdravem Jiří Pelc
>     Matematicko-fyzikální fakulta
>     Univerzita Karlova
>     _______________________________________________
>     NSWI004 mailing list
>     NSWI004 at d3s.mff.cuni.cz <mailto:NSWI004 at d3s.mff.cuni.cz>
>     https://d3s.mff.cuni.cz/mailman/listinfo/nswi004
> 
> 
> _______________________________________________
> NSWI004 mailing list
> NSWI004 at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/nswi004
>