[FIXED] popupmenu causes intuition freeze

abalaban · Post by **abalaban** » Fri Sep 09, 2011 9:41 am

chris wrote:I have been completely unable to create a test case for this, so there must be some other forces at play.

No signal available anymore ?

chris · Post by **chris** » Fri Sep 09, 2011 6:57 pm

abalaban wrote:
chris wrote:I have been completely unable to create a test case for this, so there must be some other forces at play.
No signal available anymore ?

I had considered that possibility and allocated about ten signals so signal #21 was allocated (which my faulty app was allocating). Still no problem.

I had also previously tested allocating one extra signal in the faulting app, and that allocated fine.

chris · Post by **chris** » Wed Sep 28, 2011 11:55 pm

Infurther developments it appears this is still occuring if ActivateGadget() is called before PMOPEN. If ActivateGdget() is called more than once before PMOPEN then the crash is not quite as serious, and the crashlog gives some offsets into popupmenu.library. I'm hoping these will provide some clues as to what is causing the crash.

This is one I was sent although I did manage to reproduce the crash on my machine too.

Hidden Text - Click to Show :

chris · Post by **chris** » Thu Oct 06, 2011 6:06 pm

Nobody can trace this crashlog through popupmenu.library/class and give an indication of what is causing the crash?

chris · Post by **chris** » Fri Jan 25, 2013 10:24 am

This has reared its head again.

If I call AllocSignal(), ActivateLayoutGadget(), ActivateGadget() or Trixies AmigaGuide class initialisation function (which I think just opens amigaguide.library and creates a class), popupmenu.class will then crash and deadlock Intuition the next time it is called.

It seems to be related to the particular window that I'm attaching popupmenu.class to, as if I ActivateLayoutGadget() on a different window, popupmenu.class continues to function as it should.

I'm using window.class to create the window, and my hunch is that popupmenu.class is trying to allocate something, which is failing due to something common the other calls have done, and it isn't checking the return code and ploughing on regardless.

Can somebody please look at the crashlog I posted previously and see where in popupmenu.class it is crashing?

trixie · Post by **trixie** » Fri Jan 25, 2013 5:40 pm

@chris

chris wrote:This has reared its head again.

If I call AllocSignal(), ActivateLayoutGadget(), ActivateGadget() or Trixies AmigaGuide class initialisation function (which I think just opens amigaguide.library and creates a class), popupmenu.class will then crash and deadlock Intuition the next time it is called.

If you mean the initAGClass() function then yes - all it does is open the AmigaGuide.library and then create the class:

Code: Select all

Class *initAGClass(void)
{
 Class *cl = NULL;


 // Open amigaguide.library and its interface.
 if ( (AmigaGuideBase = IExec->OpenLibrary("amigaguide.library", 52)) )
  {
   if ( (IAmigaGuide  = (struct AmigaGuideIFace *)IExec->GetInterface(AmigaGuideBase, "main", 1L, NULL)) )
    {
     if ( (cl = IIntuition->MakeClass(NULL, "rootclass", NULL, sizeof(struct localObjectData), 0)) )
      {
       cl->cl_Dispatcher.h_Entry = (HOOKFUNC)dispatchAGClass;
       IIntuition->AddClass(cl);
      }
     else freeAGClass(NULL);
    }
   else freeAGClass(NULL);
  }

 return cl;

}

The class does not reference any window, window object or any other BOOPSI class anywhere in its code so it's strange the popupmenu.class should crash after just initializing the amigaguide class. But it does allocate a signal, by calling IAmigaGuide->AmigaGuideSignal() - though the signal allocation is part of the OM_NEW method, not the initAGClass() call.

It's all really strange. I think Rigo should take a good look at the popupmenu stuff. It's been used relatively rarely in OS4 software so some bug may have escaped attention.

chris · Post by **chris** » Fri Jan 25, 2013 10:47 pm

trixie wrote:The class does not reference any window, window object or any other BOOPSI class anywhere in its code so it's strange the popupmenu.class should crash after just initializing the amigaguide class. But it does allocate a signal, by calling IAmigaGuide->AmigaGuideSignal() - though the signal allocation is part of the OM_NEW method, not the initAGClass() call.

My mistake, it's actually my init function, which also calls OM_NEW after initAGClass().

Anyway, behold the power of example code, as I've managed to get some failing code, which is in the below attachment (as an aside, I find it rather strange that an Amiga-orientated forum doesn't allow the extension "lha" for attachments). It's the vanilla Reaction popupmenu.class example, with one change - an AllocSignal(-1) before the "sticky menu" is displayed. The right-click menu is not affected.

Click on Sticky menu and it will display which signal has been allocated before opening the menu. It crashed here on 18. You will see the right-click menu (which doesn't allocate any extra signals) works infinitely.

Maybe we can finally get this fixed!

Post by **kas1e** » Sat Jan 26, 2013 12:57 pm

@Chris
Tested test case, and yes, on latest beta the same problem : on 18 everything going to deadlock (no 3 buttons works), and together with deadlock sometime bring GR with 80000003 crash.

Is such a BZ will be ok ? :

----------------
BOOPSI Classes / popupmenu class
popupmenu causes intuition freeze/deadlock and sometime 80000003 crash

Problem caused by a simple AllocSignal(-1) before popupmenu.class even opened. I.e. AllocSignal() followed by the empty menu creation seems the problem. The signal does not need to be used, just allocated!

Test case attached. It is just a vanilla Reaction popupmenu.class example, with one change - an AllocSignal(-1) before the "sticky menu" is displayed. The right-click menu is not affected.

To see problem click on Sticky menu and it will display which signal has been allocated before opening the menu. Click at that Sticky menu, untill you will not reach value 18 in output window : thats where deadlock/crash happens.

You also can see the right-click menu (which doesn't allocate any extra signals) works infinitely.
----------------

That is BZ #8227

trixie · Post by **trixie** » Sat Jan 26, 2013 5:20 pm

@chris

Yes, the thing crashes and locks up the system as soon as signal number 18 becomes allocated.

Just out of curiosity - what happens if you comment out the AmigaGuideSignal() / Wait() section in amigaguide_class.c? I mean this particular piece of the OM_SET method function:

Code: Select all

     if ( (lod->agSignal = IAmigaGuide->AmigaGuideSignal(lod->agHandle)) )
      {
       // Wait until the help system is up and running.
       IExec->Wait(lod->agSignal);
       while ( !(lod->agActive) )
        {
         while ( (lod->agm = IAmigaGuide->GetAmigaGuideMsg(lod->agHandle)) )
          {
           // The AmigaGuide process started OK.
           if ( lod->agm->agm_Type == ActiveToolID ) lod->agActive = TRUE;

           // Opening the guide file failed for some reason, continue as usual.
           if ( lod->agm->agm_Type == ToolStatusID && lod->agm->agm_Pri_Ret ) lod->agActive = TRUE;

           IAmigaGuide->ReplyAmigaGuideMsg(lod->agm);
          }
        }
      }

The class will work without it - the code just ensures that the asynschronously-started AmigaGuide document has fully been loaded and displayed.

If you get no crashes then you have another test case showing that it is signal allocation that causes the popupmenu crashes.

chris · Post by **chris** » Sat Jan 26, 2013 7:37 pm

kas1e wrote:@Chris
Tested test case, and yes, on latest beta the same problem : on 18 everything going to deadlock (no 3 buttons works), and together with deadlock sometime bring GR with 80000003 crash.

Is such a BZ will be ok ? :

----------------
BOOPSI Classes / popupmenu class
popupmenu causes intuition freeze/deadlock and sometime 80000003 crash

Problem caused by a simple AllocSignal(-1) before popupmenu.class even opened. I.e. AllocSignal() followed by the empty menu creation seems the problem. The signal does not need to be used, just allocated!

Test case attached. It is just a vanilla Reaction popupmenu.class example, with one change - an AllocSignal(-1) before the "sticky menu" is displayed. The right-click menu is not affected.

To see problem click on Sticky menu and it will display which signal has been allocated before opening the menu. Click at that Sticky menu, untill you will not reach value 18 in output window : thats where deadlock/crash happens.

You also can see the right-click menu (which doesn't allocate any extra signals) works infinitely.
----------------

That is BZ #8227

Yes, perfect, thanks!

Hyperion Entertainment Message Boards

[FIXED] popupmenu causes intuition freeze

Re: popupmenu causes intuition freeze

Re: popupmenu causes intuition freeze

Re: popupmenu causes intuition freeze

Re: popupmenu causes intuition freeze

Re: popupmenu causes intuition freeze

Re: popupmenu causes intuition freeze

Re: popupmenu causes intuition freeze

Re: popupmenu causes intuition freeze

Re: popupmenu causes intuition freeze

Re: popupmenu causes intuition freeze