[Oberon] trap output problems

[Peter Matthias]

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
>