[Oberon] trap output problems

Jan de Kruyf jan.de.kruyf at gmail.com
Sat Oct 31 08:55:21 CET 2015


Peter,

> S is not a POINTER but a RECORD.

Thanks for pointing that out. I was misled by the appearance in the trap
and did not check the source text.
It points to a very basic problem : WE WILL NOT LEARN. since I have been
here before.

I suggest that we use the Ada syntax where we need to print an attribute of
a variable (besides its immediate value) like this:

S'Address = 0008H

Or in this case maybe

S'StackRelAddr = 0008H.

(Note that I did not check that this is indeed the stack relative
address!!  I assume so)


Roel and Peter:

I ran again into corruption of my text yesterday when doing some
edit-compile-trap cycles. So this issue must be sorted.
I will put it next on my list to see if I can help anywhere.

Cheers,

j.


On Fri, Oct 30, 2015 at 11:01 PM, Peter Matthias <PeterMatthias at web.de>
wrote:

>
>
> Am 30.10.2015 um 17:14 schrieb R. P. de Jong:
>
>> Hi,
>> 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.
>>
>
> In "real" systems, it's a little bit more sophisticated.
>
> Looking into this at a little depth, my conclusion is as follows:
>>
>> During trap processing, the text system is used to print a message. This
>> generally requires a few small allocations by the text system.
>> However if the trap is caused by a heap overflow in the first place, then
>> these further allocations have a probability to also fail …
>> Unfortunately, the text system is not immune to all traps generated in
>> itself.
>> 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).
>>
>> 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.
>>
>
> 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.
>
> Regards,
>         Peter
>
>
> Regards,
>> Roel de Jong
>>
>>
>>
>> On 29 Oct, 2015, at 22:22 , Peter Matthias <PeterMatthias at web.de> wrote:
>>>
>>> Hi Jan,
>>>
>>> Am 29.10.2015 um 16:52 schrieb Jan de Kruyf:
>>>
>>>> Hallo Peter,
>>>>
>>>> I suppose the best way would be to send me the source to reproduce
>>>>>
>>>> the text corruption fault. You also can use ARM and MIPS targets via
>>>> qemu to check the behaviour.
>>>>
>>>> Here is a barebones module to demonstrate the trap printout problem.
>>>>
>>>> There are 2 pointers, one initialized (S) and one uninitialized (T).
>>>>
>>>
>>> S is not a POINTER but a RECORD.
>>>
>>> You can compile and run it as is. it will trap and give 2 values to
>>>> compare against in the kernel log.
>>>>
>>>
>>> For RECORDS, the type descriptor address is being printed. I suppose the
>>> address is relative to the static base of the module.
>>>
>>> It looks to me that the problem is in the trap printing routine.
>>>>
>>>
>>> It might be better to show the elements of the record, however, the
>>> behavior is consistent with Native Oberon.
>>>
>>> Regards,
>>>         Peter
>>> --
>>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>>>
>>
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>>
>> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20151031/2b77d3f2/attachment.html>


More information about the Oberon mailing list