[NSWI004] Adding print prevents exception 5

[Tomáš Drozdík]

Thanks for the help.

Yes I've noticed that issue with dereferencing of NULL and preventing
it with if helped. Then I thought that it could modify exception
handling which would break the rest of the code. However I'm still not
sure how adding a print solved it all at least seemingly.

I haven't really looked into gdb because previously I had some issue
with msim + gdb but I may try later on to find out exactly what is
going on.

Thanks for the help, I should have noticed NULL dereference on my own
but this behavior confused me.

Sincerely
Tomáš Drozdík


On Mon, Jan 6, 2020 at 10:52 AM Vojtech Horky <horky at d3s.mff.cuni.cz> wrote:
>
> Hello.
>
> Dne 05. 01. 20 v 21:42 Petr Tůma napsal(a):
> > Hi,
> >
> > what you describe usually happens when your data structures are corrupt - depending on exact location of things, you may or may not hit a wrong address, and when you update your code and locations change, the exact place where the exception occurs can also move.
> >
> > I would probably try to look at the addresses in thread and as, and at the address that causes the exception, perhaps that would help. We can also take a look, but please commit the code and provide us with exact commit hash and exact steps to reproduce the problem.
>
> Printing thread->as would show that it is a NULL pointer. Looking at the
> code, I would suspect that thread->as initialization does not work as
> expected for the very first thread.
>
> The weird behavior is probably a combination of multiple factors. As a
> best guess without diving too much into the code, it is quite possible
> that the NULL pointer dereference is actually translated to a physical
> address zero (due to ERL == 1 handling). Therefore you are overwriting
> your exception handling routines (their assembler parts).
>
>
> Another hint is the panic print from your exception code:
>
> Kernel panic: Exception...5, status: 0x80005364, epc: 0
>
> * EPC 0 means you would be returning to execute code at address where
> code is never placed
> * STATUS looks too much like an address rather than status code
>
> Both these things suggest corruption of the exception handling routines.
>
>
> BTW, have you tried running GDB with a breakpoint inside thread_create?
>
>
> Hope this helps,
> - VH
>
>
> >
> > By the way, writing code such as ++p->q->r is quite dangerous, few people know C operator precedence and associativity rules well enough to read this with any certainty. Writing ++(p->q->r) is more readable.
> >
> > Petr
> >
> >
> > On 04/01/2020 21:15, Tomáš Drozdík wrote:
> >> Hi,
> >>
> >> I've encountered an interesting problem that I cannot really reason about.
> >>
> >> As I was dealing with counting references to an address space my code
> >> suddenly started throwing Exception 5. Via debug prints I was able to
> >> track down when this exception is thrown. What came as a surprise is
> >> that if a place a print right before this instruction everything works
> >> properly (i.e. tests which should pass pass). Moving this print
> >> anywhere else ruins it and exception is thrown.
> >>
> >> This is a little snippet from thread_create function:
> >> ```
> >> printk("REMOVE THIS PRINT AND EXCEPTION 5 IS THROWN\n");
> >> ++thread->as->reference_counter;
> >> ```
> >> I've looked up that Exception 5 is an store to illegal address. What
> >> does it have to do with print is beyond me, obviously adding print
> >> does shift code in the memory and so it may get aligned or something.
> >> But alignment of code is compilers job. Therefore illegal address
> >> should be in memory, possibly in as_t structure but that contains just
> >> 4 integers.
> >> I don't know how much code I can paste here and even if I could I'm
> >> not even remotely aware of what can cause such behavior.
> >>
> >> Link to repo: https://gitlab.mff.cuni.cz/teaching/nswi004/winter-2019-20/team-i_cant_c/tree/as5
> >> Commit hash: 80761a068cd7f342d42e7786eaf5611419ac0487
> >>
> >> Any help would be really appreciated.
> >> Thanks in advance.
> >>
> >> Sincerly
> >> Tomáš Drozdík
> >> _______________________________________________
> >> NSWI004 mailing list
> >> 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
> >
>
> _______________________________________________
> NSWI004 mailing list
> NSWI004 at d3s.mff.cuni.cz
> https://d3s.mff.cuni.cz/mailman/listinfo/nswi004