[Openmcl-devel] armcl memory bug 1257 and v1.12-dev.4-3-gdd5622e9

[JTK]

Now I tried running a simpler case in the test for ticket 1257   (now :STRING doesn’t involve CLOS objects)

(read-from-serialized-string :string "'(1 2 3 4 5 6 7 8 9)" :loop-count 100000)

and it crashed with

====
? Unhandled exception 4 at 0x102e3a0c, context->regs at #x74d64450
? for help
[26101] Clozure CL kernel debugger: B
current thread: tcr = 0x75503068, native thread ID = 0x6612, interrupts enabled


(#x73E6A5F0) #x00018E24 : (subprimitive ret1valn)
(#x73E6A600) #x1042AA9C : #<Function READ-LIST #x14191b86> + 448
(#x73E6A630) #x00018E24 : (subprimitive ret1valn)
(#x73E6A640) #x1042B574 : #<Function %PARSE-EXPRESSION #x14191eae> + 352
(#x73E6A650) #x00018E24 : (subprimitive ret1valn)
(#x73E6A660) #x10425C08 : #<Function %READ-FORM #x1418fb06> + 452
(#x73E6A670) #x00018E24 : (subprimitive ret1valn)
(#x73E6A680) #x1042A22C : #<Function '-reader #x1419186e> + 64
(#x73E6A690) #x00018E24 : (subprimitive ret1valn)
(#x73E6A6A0) #x1042B574 : #<Function %PARSE-EXPRESSION #x14191eae> + 352
(#x73E6A6B0) #x00018E24 : (subprimitive ret1valn)
(#x73E6A6C0) #x10425C08 : #<Function %READ-FORM #x1418fb06> + 452
(#x73E6A6D0) #x00018E24 : (subprimitive ret1valn)
(#x73E6A6E0) #x10426DF8 : #<Function READ-INTERNAL #x141900ce> + 220
(#x73E6A6F0) #x10427058 : #<Function READ #x1419022e> + 124
====

But before the crash it ran at 400% CPU.

So the bug seems unsolved, it was something else unrelated the CPU at 100%
before.

> On Jan 10, 2019, at 5:42 PM, JTK <jetmonk at gmail.com> wrote:
> 
> 
> Hello,
> 
> I’m running some multithreaded programs on an RPi 3b+, and 
> I learned of memory corruption bug #1257: https://trac.clozure.com/ccl/ticket/1257 <https://trac.clozure.com/ccl/ticket/1257>
> so I decided to compile the newest opencml to see if it is still there.
> 
> Strangely, the code (read-from-serialized-string) from the above page 
> does not seem to trigger the bug after about an hour of running,
> but my question is why is this version running on only 1 CPU?
> And why does it seem much slower than before?
> 
> Top shows 100% cpu usage in  (read-from-serialized-string :thread-count 7),
> but running the same code on 1.11.5/v1.11.5 uses nearly 400% CPU, so the new version 
> 1.12-dev seems to be running on one CPU.
> 
> Running dummy loops in separate threads in 1.12-dev uses up multiple CPUs, though,
> so my 1.12-dev is definitely multithreaded.
> 
> So it’s only the task in ticket 1257 (or perhaps the lisp reader it uses?) that is single
> threaded.
> 
> Can anyone shed some light on this?  Has this bug been effectively solved, or has
> some unrelated change to threading simply mitigated it?
> 
> Thanks,
> John
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20190110/9bd126a2/attachment.htm>