<div dir="ltr">Peter,<div><br></div><div>> S is not a POINTER but a RECORD.</div><div><br></div><div>Thanks for pointing that out. I was misled by the appearance in the trap and did not check the source text.</div><div>It points to a very basic problem : WE WILL NOT LEARN. since I have been here before.</div><div><br></div><div>I suggest that we use the Ada syntax where we need to print an attribute of a variable (besides its immediate value) like this:</div><div><br></div><div>S'Address = 0008H</div><div><br></div><div>Or in this case maybe</div><div><br></div><div>S'StackRelAddr = 0008H.</div><div><br></div><div>(Note that I did not check that this is indeed the stack relative address!! I assume so)</div><div><br></div><div><br></div><div>Roel and Peter:</div><div><br></div><div>I ran again into corruption of my text yesterday when doing some edit-compile-trap cycles. So this issue must be sorted.</div><div>I will put it next on my list to see if I can help anywhere.</div><div><br></div><div>Cheers,</div><div><br></div><div>j.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 30, 2015 at 11:01 PM, Peter Matthias <span dir="ltr"><<a href="mailto:PeterMatthias@web.de" target="_blank">PeterMatthias@web.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
Am 30.10.2015 um 17:14 schrieb R. P. de Jong:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
I am not familiar with ETH Oberon, but in “Project Oberon” i found a problem with the Trap procedure which may corrupt text in the Log viewer.<br>
</blockquote>
<br></span>
In "real" systems, it's a little bit more sophisticated.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Looking into this at a little depth, my conclusion is as follows:<br>
<br>
During trap processing, the text system is used to print a message. This generally requires a few small allocations by the text system.<br>
However if the trap is caused by a heap overflow in the first place, then these further allocations have a probability to also fail …<br>
Unfortunately, the text system is not immune to all traps generated in itself.<br>
For instance, a string could be appended successfully to a Text, but its notify message call to the corresponding TextViewer could fail (generate a trap).<br>
<br>
I solved the problem for the time being by checking in the trap handler if there is still some space in the heap, otherwise i call Reset without printing a message.<br>
</blockquote>
<br></span>
AFAIR Native Oberon reserve a little bit of heap in Kernel for this purpose. OLR and other Linux Oberons allocate heap dynamically, running into this problem seldom.<br>
<br>
Regards,<br>
Peter<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regards,<br>
Roel de Jong<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 29 Oct, 2015, at 22:22 , Peter Matthias <<a href="mailto:PeterMatthias@web.de" target="_blank">PeterMatthias@web.de</a>> wrote:<br>
<br>
Hi Jan,<br>
<br>
Am 29.10.2015 um 16:52 schrieb Jan de Kruyf:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hallo Peter,<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I suppose the best way would be to send me the source to reproduce<br>
</blockquote>
the text corruption fault. You also can use ARM and MIPS targets via<br>
qemu to check the behaviour.<br>
<br>
Here is a barebones module to demonstrate the trap printout problem.<br>
<br>
There are 2 pointers, one initialized (S) and one uninitialized (T).<br>
</blockquote>
<br>
S is not a POINTER but a RECORD.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You can compile and run it as is. it will trap and give 2 values to<br>
compare against in the kernel log.<br>
</blockquote>
<br>
For RECORDS, the type descriptor address is being printed. I suppose the address is relative to the static base of the module.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It looks to me that the problem is in the trap printing routine.<br>
</blockquote>
<br>
It might be better to show the elements of the record, however, the behavior is consistent with Native Oberon.<br>
<br>
Regards,<br>
Peter<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</blockquote>
<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
<br>
</blockquote>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</div></div></blockquote></div><br></div>