[M3devel] more crashers

Mon Aug 17 17:14:44 CEST 2009

For 5.9 we should look into the libunwind/libgcc stuff.

 - Jay

----------------------------------------
> Date: Mon, 17 Aug 2009 17:13:29 +0200
> From: wagner at elegosoft.com
> To: hosking at cs.purdue.edu
> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
> Subject: Re: [M3devel] more crashers
>
> Quoting Tony Hosking :
>
>> Indeed, we might be better off investing effort in getting rid of try-
>> blocks implemented using setjmp/longjmp so as to avoid the stack-
>> allocated jmpbuf state. Or perhaps allocate that state in the heap.
>
> Is this a feature for 5.9 then? ;-)
>
> Olaf
>
>> On 17 Aug 2009, at 09:18, Jay K wrote:
>>
>>>
>>> Not as much luck as I'd like.
>>>
>>>
>>> PTHREAD_STACK_MIN
>>> Solaris: 4K
>>> Linux/sparc: 24K
>>> Linux/x86: 16K
>>> Linux/powerpc: 128K
>>>
>>>
>>> The overflowing stack, with 16K:
>>>
>>>
>>> current thread: t at 12
>>> =>[1] Rd__CharsReady(0xfd61a00c, 0xfd617410, 0xfd59fb6c, 0x0,
>>> 0xfd59fb84, 0xfd59
>>> fb8c), at 0xfec58578
>>> ---- 1 following frame from gwindows -- possible stack overflow
>>> [2] SynScan__LookChar(0xfd883670, 0xfd8aa81c, 0xfd59fb6c, 0x0,
>>> 0xfd59fb84, 0xf
>>> d59fb8c), at 0xfead71fc
>>> [3] SynScan__NextToken(0xfd883670, 0xfd8ab980, 0x9, 0x0,
>>> 0xfd59fb84, 0xfd59fb8
>>> c), at 0xfead91c4
>>> [4] SynScan__LookToken(0xfd883670, 0x4ae, 0x9, 0x0, 0xfd59fb84,
>>> 0xfd59fb8c), a
>>> t 0xfead9628
>>> [5] SynScan__HaveTokenName(0xfd883670, 0xfd5f7768, 0x8, 0x0,
>>> 0xfd59fb84, 0xfd5
>>> 9fb8c), at 0xfeadd084
>>> [6] SynParse__Read0(0xfd883654, 0xfd6174ac, 0xfd59fb6c, 0x0,
>>> 0xfd59fb84, 0xfd5
>>> 9fb8c), at 0xfeae4760
>>> [7] SynParse__Read0(0xfd883654, 0xfd617460, 0xfd59fb6c, 0x0,
>>> 0xfd59fb84, 0xfd5
>>> 9fb8c), at 0xfeae5e8c
>>>
>>>
>>> hundreds of frames of Lots of SynParse__Read0, using about 1K per
>>> frame; there is a try in there.
>>>
>>> d59fb8c), at 0xfeae348c
>>> [666] SynParse__Read0(0xfd883654, 0xfd6172d8, 0xfd59fb6c, 0x0,
>>> 0xfd59fb84, 0xf
>>> d59fb8c), at 0xfeae5e8c
>>> [667] SynParse__Read0(0xfd883654, 0xfd8aaa6c, 0xfd59fb6c, 0x0,
>>> 0xfd59fb84, 0xf
>>> d59fb8c), at 0xfeae3dd4
>>> [668] SynParse__Read0(0xfd883654, 0xfd617288, 0xfd59fb6c, 0x0,
>>> 0xfd59fb84, 0xf
>>> d59fb8c), at 0xfeae3168
>>> [669] SynParse__Read0(0xfd883654, 0xfd8aacec, 0xfd59fb6c, 0x0,
>>> 0xfd59fb84, 0xf
>>> d59fb8c), at 0xfeae6230
>>> [670] SynParse__Read1(0xfd883654, 0xfd8aacec, 0x0, 0xfd59fb84,
>>> 0xfd59fb8c, 0x0
>>> ), at 0xfeae2674
>>> [671] SynParse__Read(0xfd883654, 0xfd8aacec, 0x0, 0xfd803a00, 0x0,
>>> 0xfebee308)
>>> , at 0xfeadfb60
>>> [672] SynParse__ReadNonTerminal(0xfd883654, 0xfefed45c, 0xfd61b250,
>>> 0xfd61b8cc
>>> , 0xfd61b280, 0xfd89a27c), at 0xfeadfae8
>>> [673] ObliqParser__ParsePhrase(0xfd883654, 0x0, 0xfd61b250,
>>> 0xfd61b8cc, 0xfd61
>>> b280, 0x0), at 0xfefd5ff0
>>> [674] ObliqOnline__Interact(0xfd89a848, 0xc32a0, 0xfd61a00c, 0x1,
>>> 0x1, 0xfebee
>>> 308), at 0xff36b80c
>>> [675] ObliqRuntime__ForkedDo(0xfd3ddfb8, 0x9658aac0, 0xff000000,
>>> 0x0, 0xfd9100
>>> 90, 0x0), at 0x80db0
>>> [676] ThreadPThread__RunThread(0xef2b0, 0x0, 0x0, 0x0, 0xfd803a00,
>>> 0x1), at 0x
>>> fe06bc88
>>> [677] ThreadPThread__ThreadBase(0xef2b0, 0xfd5a0000, 0x0, 0x0,
>>> 0xfe06b7c8, 0x1
>>> ), at 0xfe06b818
>>>
>>>
>>> One of the problems with defining a unit of stack size is the large
>>> variety of jmpbuf size.
>>> But heck, why 1K per frame here when SOLsun has a stack walker? Hm.
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: wagner at elegosoft.com; m3devel at elegosoft.com
>>>> Subject: RE: [M3devel] more crashers
>>>> Date: Mon, 17 Aug 2009 11:35:40 +0000
>>>>
>>>>
>>>> - I think the whole machine stack mechanism is pretty hopelessly broken.
>>>> Not just in Modula-3. Therefore my enthusiasm to attempt to "fix"
>>>> it -- which is impossible -- isn't very high.
>>>>
>>>> - I'm hoping to find that no platform other than Solaris lets you
>>>> even use such a small stack. I have to experiment some in a bit.
>>>> Depending on that experiment, we'll be in a better position, without
>>>> any further changes, but again, depending on what I find.
>>>> That is, if every other platform already had a larger stack, then this
>>>> just brings Solaris inline with the rest. If the other platforms
>>>> were actually successfully using a 4K stack, then indeed a problem.
>>>>
>>>>
>>>> - It could also be a factor of optimization.
>>>> Maybe ensuring -O2 or -O3 is used more would cover it up??
>>>>
>>>>
>>>> - Or some other changes.
>>>> That is, if we have drastically increased stack usage, we should try
>>>> to reduce it back down. But given that 4K was the previous value
>>>> and even 16K doesn't work...I'm not hopeful we could fit it back
>>>> down in 4K.
>>>>
>>>> It is easy enough to see the bug and then look at the various frames
>>>> and see if they use a lot of stack and can be reduced.
>>>>
>>>> - Jay
>>>>
>>>>
>>>>
>>>> ----------------------------------------
>>>>> Date: Mon, 17 Aug 2009 13:30:26 +0200
>>>>> From: wagner at elegosoft.com
>>>>> To: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] more crashers
>>>>>
>>>>> Quoting Jay K :
>>>>>
>>>>>> visobliq was stack overflow.
>>>>>> Raising the default from 4K to 16K didn't fix, but 32K did.
>>>>>
>>>>> We need to address this somehow. It cannot be correct if the user
>>>>> needs to increase the default stack size on one platform by 8
>>>>> and not at all on another. Do we have any concept of a 'standard
>>>>> stack size unit' ;-)? Something that can be easily understood and
>>>>> implemented and be used instead of the machine words in the current
>>>>> interfaces? Any ideas?
>>>>>
>>>>> Olaf
>>>>>
>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: jay.krell at cornell.edu
>>>>>>> To: hosking at cs.purdue.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: RE: [M3devel] more crashers
>>>>>>> Date: Sun, 16 Aug 2009 20:32:31 +0000
>>>>>>>
>>>>>>>
>>>>>>> m3browser:
>>>>>>>
>>>>>>> It is specific to my config file
>>>>>>> m3-sys/cminstall/src/config-no-install/cm3.cfg that reachs back
>>>>>>> into the source tree. It won't happen with what most people do. I
>>>>>>> have to do that M3Predefines or such work so that all the uses of
>>>>>>> m3quake besides cm3 are much more like cm3.
>>>>>>>
>>>>>>>
>>>>>>> visobliq:
>>>>>>> not the same thing
>>>>>>> Does not occur on Linux/x86 or Linux/sparc.
>>>>>>> They do print
>>>>>>> Syntax error just before: -helvetica-bold-\*R-\*240-\*\") (LabelFo ...
>>>>>>> ill-formed character escape sequence
>>>>>>> Error detected (file file generated by Visual Obliq) (line 18, char 10)
>>>>>>> VideoVBT.Start Jv ServerFailure:errno=0
>>>>>>>
>>>>>>> but then gui comes up.
>>>>>>> I'll have to finish my Solaris reinstall and get dbx.
>>>>>>>
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>> Date: Sun, 16 Aug 2009 20:22:49 +0000
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] more crashers
>>>>>>>>
>>>>>>>>
>>>>>>>> sorry, this is simple.
>>>>>>>>
>>>>>>>> derived_dirs := IntList.List1 (ID.Add (MxConfig.Get("BUILD_DIR")));
>>>>>>>>
>>>>>>>>
>>>>>>>> - Jay
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------
>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>> Date: Sun, 16 Aug 2009 19:52:03 +0000
>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>> Subject: Re: [M3devel] more crashers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Here is the relevant code in m3browser ID.m3:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> C:\dev2\cm3.2\m3-tools\m3markup\src\ID.m3(38): empty_id := Add ("");
>>>>>>>>>
>>>>>>>>> empty_id := Add ("");
>>>>>>>>>
>>>>>>>>> (*--------------------------------------------------------------
>>>>>>>>> exported ---*)
>>>>>>>>> PROCEDURE Add (x: TEXT): T =
>>>>>>>>> VAR
>>>>>>>>> t: T;
>>>>>>>>> a: REF ARRAY OF CHAR;
>>>>>>>>> l: INTEGER;
>>>>>>>>> BEGIN
>>>>>>>>> l := Text.Length(x);
>>>>>>>>> ...
>>>>>>>>> END Add;
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The empty string constant ends up as null.
>>>>>>>>>
>>>>>>>>> .stabn 68,0,38,.LM115-.LFBB10
>>>>>>>>> .LM115:
>>>>>>>>> movl L_1 at GOT(%ebx), %eax
>>>>>>>>> leal 24(%eax), %eax
>>>>>>>>> movl %eax, (%esp)
>>>>>>>>> call ID__Add at PLT
>>>>>>>>> movl %eax, -8(%ebp)
>>>>>>>>> movl -8(%ebp), %ecx
>>>>>>>>> movl MM_ID at GOT(%ebx), %edx
>>>>>>>>> movl 248(%edx), %eax
>>>>>>>>> andl $0, %eax
>>>>>>>>> orl %ecx, %eax
>>>>>>>>> movl %eax, 248(%edx)
>>>>>>>>> .L136:
>>>>>>>>> movl MM_ID at GOT(%ebx), %eax
>>>>>>>>> .LBE16:
>>>>>>>>> addl $52, %esp
>>>>>>>>> popl %ebx
>>>>>>>>> popl %ebp
>>>>>>>>> ret
>>>>>>>>>
>>>>>>>>> L_1:
>>>>>>>>> 0 .long RTHooks__TextLitInfo
>>>>>>>>> 4 .long RTHooks__TextLitGetChar
>>>>>>>>> 8 .long RTHooks__TextLitGetWideChar
>>>>>>>>> 12 .long RTHooks__TextLitGetChars
>>>>>>>>> 16 .long RTHooks__TextLitGetWideChars
>>>>>>>>> 20 .long 2
>>>>>>>>> 24 .long L_1
>>>>>>>>> .long 0
>>>>>>>>> .zero 4
>>>>>>>>> .ascii "ID_M3"
>>>>>>>>> .zero 1
>>>>>>>>> .ascii "ExpandHashTable"
>>>>>>>>> .zero 1
>>>>>>>>> .ascii "ExpandIDs"
>>>>>>>>> .zero 1
>>>>>>>>> .ascii "ExpandChars"
>>>>>>>>> .zero 1
>>>>>>>>> .ascii "Compare"
>>>>>>>>> .zero 1
>>>>>>>>>
>>>>>>>>> If I change "" to "foo", I get:
>>>>>>>>>
>>>>>>>>> L_1:
>>>>>>>>> 0 .long RTHooks__TextLitInfo
>>>>>>>>> 4 .long RTHooks__TextLitGetChar
>>>>>>>>> 8 .long RTHooks__TextLitGetWideChar
>>>>>>>>> 12 .long RTHooks__TextLitGetChars
>>>>>>>>> 16 .long RTHooks__TextLitGetWideChars
>>>>>>>>> 20 .long 2
>>>>>>>>> 24 .long L_1
>>>>>>>>> .long 3
>>>>>>>>> .ascii "foo"
>>>>>>>>> .zero 1
>>>>>>>>> .ascii "ID_M3"
>>>>>>>>>
>>>>>>>>> and it still crashes.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It seems to hit ID__Add twice when only once would be expected.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> - Jay
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----------------------------------------
>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>> To: hosking at cs.purdue.edu
>>>>>>>>>> Date: Sun, 16 Aug 2009 19:33:34 +0000
>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>> Subject: Re: [M3devel] more crashers
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Could be. I've also seen it on PPC_DARWIN a while ago. I only
>>>>>>>>>> recall seeing it on sparc and ppc.
>>>>>>>>>> It doesn't always occur.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Here is the m3browser crash on a system that can be debugged.
>>>>>>>>>> See why I want the full paths in the debug info?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> C:\Users\jay\Desktop>\cygwin\bin\ssh xobsd.
>>>>>>>>>> $ cd /cm3
>>>>>>>>>> $ cd bin
>>>>>>>>>> $ export DISPLAY=192.168.1.120:0.0
>>>>>>>>>> $ gdb ./m3browser
>>>>>>>>>> GNU gdb 6.3
>>>>>>>>>> This GDB was configured as "i386-unknown-openbsd4.5"...
>>>>>>>>>> (gdb) r
>>>>>>>>>> Starting program: /home/jay/cm3/bin/m3browser
>>>>>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>>>>>> [Switching to process 31063, thread 0x7eafe800]
>>>>>>>>>> 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/text/
>>>>>>>>>> Text.m3:16
>>>>>>>>>> 16 t.get_info (i);
>>>>>>>>>> (gdb) bt
>>>>>>>>>> #0 0x01592fd4 in Text__Length (M3_Bd56fi_t=0x0) at ../src/
>>>>>>>>>> text/Text.m3:16
>>>>>>>>>> #1 0x09fd9464 in ID__Add (M3_Bd56fi_x=0x0) at ../src/ID.m3:48
>>>>>>>>>> #2 0x1c01e644 in Main_M3 (M3_AcxOUs_mode=1) at ../src/ Main.m3:37
>>>>>>>>>> #3 0x0156f1bc in RTLinker__RunMainBody (M3_DjPxE3_m=0x3c003ec0)
>>>>>>>>>> at ../src/runtime/common/RTLinker.m3:399
>>>>>>>>>> #4 0x0156e576 in RTLinker__AddUnitI (M3_DjPxE3_m=0x3c003ec0)
>>>>>>>>>> at ../src/runtime/common/RTLinker.m3:113
>>>>>>>>>> #5 0x0156e604 in RTLinker__AddUnit (M3_DjPxE5_b=0x1c01e54d)
>>>>>>>>>> at ../src/runtime/common/RTLinker.m3:122
>>>>>>>>>> #6 0x1c004676 in main (argc=1, argv=0xcfbf6a3c, envp=0xcfbf6a44)
>>>>>>>>>> at _m3main.mc:4
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> - Jay
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ________________________________
>>>>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>>>>> Date: Sun, 16 Aug 2009 15:26:49 -0400
>>>>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>>>>> Subject: Re: [M3devel] more crashers
>>>>>>>>>>>
>>>>>>>>>>> Could this be endianness-related?
>>>>>>>>>>>
>>>>>>>>>>> On 16 Aug 2009, at 15:21, Jay K wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I see the assertion failure on PPC_LINUX too.
>>>>>>>>>>> I tried VAR defaultStackSize := 1024 * 1024; (not sure why
>>>>>>>>>>> there was any suspicion of stack size).
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Debugging doesn't work PPC_LINUX.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> jay at plin:/cm3/bin$ gdb ./cm3
>>>>>>>>>>> GNU gdb 6.8-debian
>>>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc.
>>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later
>>>>>>>>>>> This is free software: you are free to change and redistribute it.
>>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type
>>>>>>>>>>> "show copying"
>>>>>>>>>>> and "show warranty" for details.
>>>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"...
>>>>>>>>>>> break ma(gdb) break main
>>>>>>>>>>> Breakpoint 1 at 0x86fc4: file _m3main.mc, line 2.
>>>>>>>>>>> (gdb) r
>>>>>>>>>>> Starting program: /home/jay/cm3/bin/cm3
>>>>>>>>>>> Warning:
>>>>>>>>>>> Cannot insert breakpoint 1.
>>>>>>>>>>> Error accessing memory address 0x86fc4: Input/output error.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> No problem with C:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> jay at plin:/cm3/bin$ echo "main(){}"> 1.c
>>>>>>>>>>> jay at plin:/cm3/bin$ gcc -g 1.c
>>>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out
>>>>>>>>>>> GNU gdb 6.8-debian
>>>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc.
>>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later
>>>>>>>>>>> This is free software: you are free to change and redistribute it.
>>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type
>>>>>>>>>>> "show copying"
>>>>>>>>>>> and "show warranty" for details.
>>>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"...
>>>>>>>>>>> (gdb) break main
>>>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1.
>>>>>>>>>>> (gdb) r
>>>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out
>>>>>>>>>>> Breakpoint 1, main () at 1.c:1
>>>>>>>>>>> 1 main(){}
>>>>>>>>>>> (gdb)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs+ 1.c
>>>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out
>>>>>>>>>>> GNU gdb 6.8-debian
>>>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc.
>>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later
>>>>>>>>>>> This is free software: you are free to change and redistribute it.
>>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type
>>>>>>>>>>> "show copying"
>>>>>>>>>>> and "show warranty" for details.
>>>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"...
>>>>>>>>>>> (gdb) break main
>>>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1.
>>>>>>>>>>> (gdb) r
>>>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out
>>>>>>>>>>> Breakpoint 1, main () at 1.c:1
>>>>>>>>>>> 1 main(){}
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> jay at plin:/cm3/bin$ gcc -gstabs 1.c
>>>>>>>>>>> jay at plin:/cm3/bin$ gdb ./a.out
>>>>>>>>>>> GNU gdb 6.8-debian
>>>>>>>>>>> Copyright (C) 2008 Free Software Foundation, Inc.
>>>>>>>>>>> License GPLv3+: GNU GPL version 3 or later
>>>>>>>>>>> This is free software: you are free to change and redistribute it.
>>>>>>>>>>> There is NO WARRANTY, to the extent permitted by law. Type
>>>>>>>>>>> "show copying"
>>>>>>>>>>> and "show warranty" for details.
>>>>>>>>>>> This GDB was configured as "powerpc-linux-gnu"...
>>>>>>>>>>> (gdb) break main
>>>>>>>>>>> Breakpoint 1 at 0x10000448: file 1.c, line 1.
>>>>>>>>>>> (gdb) r
>>>>>>>>>>> Starting program: /home/jay/cm3/bin/a.out
>>>>>>>>>>> Breakpoint 1, main () at 1.c:1
>>>>>>>>>>> 1 main(){}
>>>>>>>>>>> (gdb)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - Jay
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>> From: jay.krell at cornell.edu
>>>>>>>>>>> To: m3devel at elegosoft.com
>>>>>>>>>>> Subject: more crashers
>>>>>>>>>>> Date: Sun, 16 Aug 2009 10:06:15 +0000
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This is head on SOLgnu:
>>>>>>>>>>> I'll try another and debug and see if fix is easy.
>>>>>>>>>>>
>>>>>>>>>>> -bash-3.00$ ./m3browser
>>>>>>>>>>>
>>>>>>>>>>> ***
>>>>>>>>>>> *** runtime error:
>>>>>>>>>>> *** Segmentation violation - possible attempt to dereference NIL
>>>>>>>>>>> *** pc = 0xfe484f04 = String16_M3 + 0xe0 in ../src/text/ String16.m3
>>>>>>>>>>> ***
>>>>>>>>>>>
>>>>>>>>>>> -bash-3.00$ ./visobliq
>>>>>>>>>>> Internal Obliq interpreter installed...
>>>>>>>>>>> Establishing 'templates'
>>>>>>>>>>> (Created frame 'templates')
>>>>>>>>>>> let
>>>>>>>>>>> Templates =
>>>>>>>>>>> {boolean=> ... ,
>>>>>>>>>>> browser=> ... ,
>>>>>>>>>>> button=> ... ,
>>>>>>>>>>> choice=> ... ,
>>>>>>>>>>> filebrowser=> ... ,
>>>>>>>>>>> form=> ... ,
>>>>>>>>>>> frame=> ... ,
>>>>>>>>>>> hscroll=> ... ,
>>>>>>>>>>> menu=> ... ,
>>>>>>>>>>> numeric=> ... ,
>>>>>>>>>>> text=> ... ,
>>>>>>>>>>> textedit=> ... ,
>>>>>>>>>>> typein=> ... ,
>>>>>>>>>>> video=> ... ,
>>>>>>>>>>> vscroll=> ... }
>>>>>>>>>>> Establishing 'vowidgets'
>>>>>>>>>>> (Created frame 'vowidgets')
>>>>>>>>>>> ok
>>>>>>>>>>> Establishing 'vocheckpt'
>>>>>>>>>>> (Created frame 'vocheckpt')
>>>>>>>>>>> ok
>>>>>>>>>>> Establishing 'volib'
>>>>>>>>>>> (Created frame 'volib')
>>>>>>>>>>> Segmentation Fault (core dumped)
>>>>>>>>>>> -bash-3.00$
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Olaf Wagner -- elego Software Solutions GmbH
>>>>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
>>>>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23
>>>>> 45 86 95
>>>>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
>>>>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr:
>>>>> DE163214194
>>>>>
>
>
>
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>