Re: [squeak-dev] re: "callback failed to own the VM"

 

     Hm, maybe a clue? Here's my callback thread (thread 3, zero-based
index) trying to own the VM:

***

Breakpoint 1, ownVM (threadIndexAndFlags=131075) at
/home/craig/Cog/src/vm/gcc3x-cointerpmt.c:17544
17544 printf("ownvm: %u\n", threadIndex);
(gdb) info threads
Id Target Id Frame
* 4 Thread 0x85fabb40 (LWP 12278) "squeak" ownVM
(threadIndexAndFlags=131075) at
/home/craig/Cog/src/vm/gcc3x-cointerpmt.c:17544
3 Thread 0x86feeb40 (LWP 12277) "squeak" 0xb7fdd428 in __kernel_vsyscall ()
2 Thread 0x8780fb40 (LWP 12276) "squeak" 0xb7fdd428 in __kernel_vsyscall ()
1 Thread 0xb7daf700 (LWP 12270) "squeak" 0xb7fdd428 in __kernel_vsyscall ()
(gdb) bt
#0 ownVM (threadIndexAndFlags=131075) at
/home/craig/Cog/src/vm/gcc3x-cointerpmt.c:17544
#1 0x0807b998 in ownVMFromUnidentifiedThread () at
/home/craig/Cog/src/vm/gcc3x-cointerpmt.c:17490
#2 0x0807b9ad in ownVM (threadIndexAndFlags=0) at
/home/craig/Cog/src/vm/gcc3x-cointerpmt.c:17541
#3 0x0811385d in thunkEntry (thunkp=0x8292030, stackp=0x85fab2a8) at
/home/craig/Cog/platforms/Cross/plugins/IA32ABI/ia32abicc.c:191
#4 0x08292042 in ?? ()
#5 0x867b9519 in _mids_channel_fsm_proc () from
/usr/lib/libgnsdk_musicid_stream.so.3.07.7
#6 0x8626e49c in _gcsl_thread_proc () from /usr/lib/libgnsdk_dsp.so.3.07.7
#7 0xb7fabf70 in start_thread (arg=0x85fabb40) at pthread_create.c:312
#8 0xb7e9bbee in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129
(gdb) n
ownvm: 3
17545 flags = ((usqInt) threadIndexAndFlags) >> DisownFlagsShift;
(gdb) n
17546 if (flags & DisownVMForProcessorRelinquish) {
(gdb) n
17550 if (threadIndexAndFlags & LockGUIThreadFlag) {
(gdb) n
17571 assert(threadIndex == (ioGetThreadLocalThreadIndex()));
(gdb) n
17573 assert(((threadIndex >= 1) && (threadIndex <= GIV(numThreads))));
(gdb) n
17574 vmThread1 = GIV(threads)[threadIndex];
(gdb) n
17575 assert((((vmThread1->state)) == CTMUnavailable)
(gdb) n
17577 if (!(tryLockVMToIndex(threadIndex))) {
(gdb) n
ownvm: 1
17578 (vmThread1->state = CTMWantingOwnership);
(gdb)

***

     When I stepped over tryToLockVMToIndex(), the heartbeat thread
(thread 1, zero-based index) entered ownVM(). How was that possible?


     thanks,

-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

 

     Also, should the interpret() thread be hanging around in
primitiveRelinquishProcessor() while doing sendInvokeCallbackContext()?


     thanks,

-C

***

(gdb) info threads
Id Target Id Frame
4 Thread 0x85fabb40 (LWP 5345) "squeak" 0xb7fdd428 in __kernel_vsyscall ()
3 Thread 0x86feeb40 (LWP 5334) "squeak" 0xb7fdd428 in __kernel_vsyscall ()
2 Thread 0x8780fb40 (LWP 5333) "squeak" 0xb7fdd428 in __kernel_vsyscall ()
* 1 Thread 0xb7daf700 (LWP 5324) "squeak" 0xb7fdd428 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fdd428 in __kernel_vsyscall ()
#1 0xb7fafd4b in pthread_cond_wait@@GLIBC_2.3.2 () at
../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:187
#2 0x08060ece in ioWaitOnOSSemaphore (sem=0x823db54) at
/home/craig/Cog/platforms/unix/vm/sqUnixThreads.c:128
#3 0x0807bbeb in ownVM (threadIndexAndFlags=2621441) at
/home/craig/Cog/src/vm/gcc3x-cointerpmt.c:17594
#4 0x0807cb9d in primitiveRelinquishProcessor () at
/home/craig/Cog/src/vm/gcc3x-cointerpmt.c:18022
#5 0x08066714 in interpret () at
/home/craig/Cog/src/vm/gcc3x-cointerpmt.c:5320
#6 0x0807ae77 in enterSmalltalkExecutiveImplementation () at
/home/craig/Cog/src/vm/gcc3x-cointerpmt.c:17048
#7 0x0807decd in threadSchedulingLoop (vmThread=0x823db48) at
/home/craig/Cog/src/vm/gcc3x-cointerpmt.c:18729
#8 0x0807d93c in sendInvokeCallbackContext
(vmCallbackContext=0xbff5b7f8) at
/home/craig/Cog/src/vm/gcc3x-cointerpmt.c:18546
#9 0x08113914 in thunkEntry (thunkp=0x8252018, stackp=0xbff5b968) at
/home/craig/Cog/platforms/Cross/plugins/IA32ABI/ia32abicc.c:203
#10 0x0825202a in ?? ()
#11 0x87009ea9 in createIdentificationChannel
(callbacksPointer=0x8247c60, channelPointer=0x8248008,
managerPointer=0x8247e98, userPointer=0x8247df0,
localePointer=0x8247e28, callbackData=0x8247c88) at gracefulAlien.c:127
#12 0x0811292f in callIA32IntegralReturn (argVector=0x8913c180,
numArgs=6, funcOffset=2, resultOffset=1)
at /home/craig/Cog/platforms/Cross/plugins/IA32ABI/dabusiness.h:151
#13 0x081121cf in primVarArgsCallOutIntegralReturn () at
/home/craig/Cog/src/plugins/IA32ABI/IA32ABI.c:1931
#14 0x080aef93 in primitiveExternalCall () at
/home/craig/Cog/src/vm/gcc3x-cointerpmt.c:53198
#15 0x08066714 in interpret () at
/home/craig/Cog/src/vm/gcc3x-cointerpmt.c:5320
#16 0x0807ae77 in enterSmalltalkExecutiveImplementation () at
/home/craig/Cog/src/vm/gcc3x-cointerpmt.c:17048
#17 0x0807decd in threadSchedulingLoop (vmThread=0x823db48) at
/home/craig/Cog/src/vm/gcc3x-cointerpmt.c:18729
#18 0x0807b00f in initialEnterSmalltalkExecutive () at
/home/craig/Cog/src/vm/gcc3x-cointerpmt.c:17129
#19 0x080613ae in interpret () at
/home/craig/Cog/src/vm/gcc3x-cointerpmt.c:2301
#20 0x0805f991 in main (argc=2, argv=0xbffff184, envp=0xbffff190) at
/home/craig/Cog/platforms/unix/vm/sqUnixMain.c:1968
(gdb)

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

 

> ...I have no cycles to think about this right now.

     When do you think you might? I'm getting nowhere and should drop it.


     thanks,

-C

--
Craig Latta
netjam.org
+31   6 2757 7177 (SMS ok)
+ 1 415  287 3547 (no SMS)

 

 
Good evening,

I hope you don't view my comments as a bother on this topic, yet I had
just told Craig I didn't think I needed this so...  Well, my interest
was gettting NIO to work, so it's industrial on that networking side of
the house. NIO isn't hot with large amounts of data but with large
numbers of connections it excels.

It has been my firm belief over 21 years of Smalltalking, perhaps not
actively, that Smalltalk was made for the server. With the right
programming idioms, large numbers of smaller slower machines has the
potential and capacity to outperform the large. Truthfully, I think
programming in swarms is cool. NIO is a server solution.

Ok, let me take a haircut, here: NIO is a blocking callout - no
callbacks, but since it is blocking, I realized today that the select
callout would block the VM.

64-bit is so cool, in my view because of the increased usage of
immediates...also an idea I shared that we could have 2 32-bit
hyperthreads; totally cool. But this is a capacity problem being solved,
isn't it? What capability does it offer us that we currently do not have?

The Threaded VM, on the other hand, provides definite feature additions:
1) real event image without so many monitor processes, 2) callbacks and
blocking callouts, 3) multiple images on separate OS threads with shared
memory. There may be others and negatives I don't know about.

Thanks for listening,
Robert

On 10/12/2015 07:33 PM, Eliot Miranda wrote: