bugGNUstep - Bugs: bug #21724, Crash when re-opening panel that...

Group
 
 

bug #21724: Crash when re-opening panel that has been previously closed...

Submitter:  Gregory John Casamento <gcasa>
Submitted:  Wed 05 Dec 2007 01:17:38 AM UTC
   
 
Category:  Gui/AppKit Severity:  4 - Important
Item Group:  Bug Status:  Works For Me
Privacy:  Public Assigned to:  gcasa
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 02 Jan 2008 04:30:11 AM UTC, comment #9: 

I tried to make some changes to the repair method which would correct this type of problem. 

The issue is that the connections are pointing to names which don't exist in the nametable, and there's no way to guess which object they should point to.

At any rate, this is a bug that was long ago corrected in Gorm and doesn't appear to be a bug in GNUstep itself at this point and is, unfortunately, a case where the file will need to be recreated.

Later, GJC

Gregory John Casamento <gcasa>
Group administrator
Tue 01 Jan 2008 10:25:13 PM UTC, comment #8: 

Just a note... the file in question is PRConvolve55.gorm

(file #14731)

Gregory John Casamento <gcasa>
Group administrator
Tue 01 Jan 2008 10:23:21 PM UTC, comment #7: 

I believe I have another clue to what might be happening.  I think you're on the right track with the gorm file corruption.

If you open the gorm file and go to the connections editor, then select NSOwner you'll see all of the connections for the outlets of that object (which is an instance of PRCConvolve55).

Now, if you select one of those connections Gorm should highlight the source and target using the S and T icons.  You'll note it doesn't do that.   I tried disconnecting and reconnecting one of the buttons (for me it was the "Auto" button) and when it read-added it it had a different name "Button3" whereas, previously, it was "Button."   This indicates that there is an entry in the nametable that is incorrect.

This gorm file was created by an early version of Gorm (perhaps a development version) and the name table is corrupted.  I know this because I remember helping Riccardo when he was working on PRICE a while back. :)

I believe that Gorm, within reason, should be able to correct this when it loads a "corrupt" gorm file.   The nametable is just one section of the Gorm file's data structure which can be rebuilt.

GJC

Gregory John Casamento <gcasa>
Group administrator
Tue 01 Jan 2008 09:22:37 PM UTC, comment #6: 

Thank you, now I understand what your test code was for.

I had another go with the Price application and it turns out, it has nothing to do with the closing of the window. Even without closing that window, just selecting it again in the menu the applications crashes. I started to debug this and it seems that the text field pointers get corrupted. Here some debug output.

Before loading the window:
(gdb) p *self
$1 = {{isa = 0x8071380}, filterWindow = 0x0, matField11 = 0x0,
  matField12 = 0x0, matField13 = 0x0, matField14 = 0x0, matField15 = 0x0,
  matField21 = 0x0, matField22 = 0x0, matField23 = 0x0, matField24 = 0x0,
  matField25 = 0x0, matField31 = 0x0, matField32 = 0x0, matField33 = 0x0,
  matField34 = 0x0, matField35 = 0x0, matField41 = 0x0, matField42 = 0x0,
  matField43 = 0x0, matField44 = 0x0, matField45 = 0x0, matField51 = 0x0,
  matField52 = 0x0, matField53 = 0x0, matField54 = 0x0, matField55 = 0x0,
  scaleField = 0x0, offsetField = 0x0, autoScaleCheck = 0x0,
  convMatrix = {{0, 0, 0, 0, 0}, {0, 0, 0, 0, 0}, {0, 0, 0, 0, 0}, {0, 0,
      0, 0, 0}, {0, 0, 0, 0, 0}}, autoScale = 0 '\0', offset = 0,
  scale = 0}


After loading it (note that matField12 is already wrong!):
(gdb) p *self
$2 = {{isa = 0x8071380}, filterWindow = 0x847f5e8,
  matField11 = 0x907cad0, matField12 = 0x0, matField13 = 0x82f2210,
  matField14 = 0x82e4250, matField15 = 0x838f8d0, matField21 = 0x83164c0,
  matField22 = 0x83fb6d8, matField23 = 0x83cc300, matField24 = 0x84788b8,
  matField25 = 0x9067370, matField31 = 0x8474e98, matField32 = 0x82eff98,
  matField33 = 0x82ff9f8, matField34 = 0x83fc368, matField35 = 0x847ed40,
  matField41 = 0x839e4e8, matField42 = 0x8318270, matField43 = 0x8401258,
  matField44 = 0x8318860, matField45 = 0x83161c8, matField51 = 0x83faec8,
  matField52 = 0x83fa998, matField53 = 0x83f6860, matField54 = 0x841b398,
  matField55 = 0x833f118, scaleField = 0x8416de8,
  offsetField = 0x842aad8, autoScaleCheck = 0x9065c18, convMatrix = {{0,
      0, 0, 0, 0}, {0, 0, 0, 0, 0}, {0, 0, 0, 0, 0}, {0, 0, 0, 0, 0}, {0,
      0, 0, 0, 0}}, autoScale = 0 '\0', offset = 0, scale = 0}

(gdb)  p *(self->matField11)
$2 = {{{{{isa = 0xb7f658e0}, _interface_style = NSNoInterfaceStyle,
        _next_responder = 0x0, _menu = 0x0}, _frame = {origin = {x = 13,
          y = 261}, size = {width = 40, height = 21}}, _bounds = {
        origin = {x = 0, y = 0}, size = {width = 40, height = 21}},
      _frameMatrix = 0x0, _boundsMatrix = 0x0,
      _matrixToWindow = 0x82dcea8, _matrixFromWindow = 0x82ce3b8,
      _super_view = 0x0, _sub_views = 0x83a9790, _window = 0x0,
      _tracking_rects = 0x832a078, _cursor_rects = 0x83a1b10,
[...]

Now after opening once more from the menu:
(gdb)  p *self
$5 = {{isa = 0x8071380}, filterWindow = 0x8489058,
  matField11 = 0x82ce2f8, matField12 = 0x0, matField13 = 0x83b0e18,
  matField14 = 0x8414e08, matField15 = 0x83fea58, matField21 = 0x926e288,
  matField22 = 0x83ffca0, matField23 = 0x9270de8, matField24 = 0x8476688,
  matField25 = 0x841ab88, matField31 = 0x83fa8b8, matField32 = 0x84155f0,
  matField33 = 0x9263ae0, matField34 = 0x83f4060, matField35 = 0x847c828,
  matField41 = 0x83a0f60, matField42 = 0x8316da8, matField43 = 0x925b148,
  matField44 = 0x83b2c10, matField45 = 0x83a3ae0, matField51 = 0x8414618,
  matField52 = 0x83fed80, matField53 = 0x840f8e0, matField54 = 0x83fb318,
  matField55 = 0x83f9998, scaleField = 0x8333768,
  offsetField = 0x82f1a58, autoScaleCheck = 0x847a0a0, convMatrix = {{0,
      0, 0, 0, 0}, {0, 0, 0, 0, 0}, {0, 0, 1, 0, 0}, {0, 0, 0, 0, 0}, {0,
      0, 0, 0, 0}}, autoScale = 0 '\0', offset = 0, scale = 1}

(gdb) p *(self->matField11)
$4 = {{{{{isa = 0x40c00000}, _interface_style = NSNoInterfaceStyle,
        _next_responder = 0x0, _menu = 0x0}, _frame = {origin = {x = 0,
          y = -1.5095211e-05}, size = {width = -6.26827951e+18,
          height = 0}}, _bounds = {origin = {x = 0, y = 2.92871379e-43},
        size = {width = 1.99760571e-33, height = -1.5095211e-05}},
      _frameMatrix = 0xdeadface, _boundsMatrix = 0x0,
      _matrixToWindow = 0x0, _matrixFromWindow = 0xb9,
      _super_view = 0x925f460, _sub_views = 0xb77d4170,
      _window = 0x7474726f, _tracking_rects = 0x8657079,

As you can see the isa pointer of the text field has changed and the same is true of the other text fields as well.

What I tired to do next was to load the Gorm file for the window, but there was nothing unusual, apart from the not connected second text field.

Finally I hacked in some output into the convMatrix11: method so see if the sender was the same object as the text field matField11 and it wasn't. So I would say that the Gorm file is totally corrupt and should be reproduced from scratch.

On MacOSX this problem could of course not occure as there a separate NIB file is used. Perhaps the same NIB file converted to the new format could be used in both cases to avoid this problem in the future.

Fred Kiefer <FredKiefer>
Group Member
Mon 31 Dec 2007 04:41:10 PM UTC, comment #5: 

Fred,

I was trying to reproduce the problem when I wrote the demo application, since it was previously suggested that it was a gorm loading issue and that the connections should retain their targets.

Since the demo application works properly, it proves that that is not the case, so something else must be occurring.

GJC


Gregory John Casamento <gcasa>
Group administrator
Mon 31 Dec 2007 02:21:03 PM UTC, comment #4: 

Could you please report on how to reproduce this problem with your demo applications? I tried to open the panel, close it, open it again and so on, but it just keeps on working. Even when pressing that nice button in between it still reopens the next time.
I was able to reproduce the original problem in Price, perhaps I should also check that again.

Fred Kiefer <FredKiefer>
Group Member
Mon 31 Dec 2007 12:14:09 AM UTC, comment #3: 

I've attached a demonstration project that illustrates that it's not a gorm loading issue.   I am still investigating.

GJC

(file #14724)

Gregory John Casamento <gcasa>
Group administrator
Thu 06 Dec 2007 04:13:33 AM UTC, comment #2: 

The window is set to not release when closed.  Also, the window is a top level object and is retained in an array of top level objects that is returned to the application.

I will look into this issue more deeply in the next couple of days.

Gregory John Casamento <gcasa>
Group administrator
Thu 06 Dec 2007 12:22:05 AM UTC, comment #1: 

I had a short look at the Price code and from that I would say it is a Gorm decoding problem. In the crashing method [PRCConvolve55 showConvolve55:] a gorm file gets loaded and the window is most likely connected to an instnace variable. Later, when this variable is reused again after closing the window the object is gone. Looks like Gorm loading should hold on to objects being connected.

Fred Kiefer <FredKiefer>
Group Member
Wed 05 Dec 2007 01:17:38 AM UTC, original submission:  

Steps to reproduce:

1) Download an build PRICE.app
2) open an image
3) Choose Convolve from the Filters menu
4) Close the Convolve panel
5) Re-open the panel and try again

RESULT: Crash
EXPECTED: Panel should open and should be able to use matrix.

While looking at this I noticed some interesting code in the close method in NSWindow which I have some questions about.

I tested the same application on Mac OS X and couldn't get a similar failure.

GJC

Gregory John Casamento <gcasa>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #14731:  Convolve55.gorm.tgz added by gcasa (6KiB - application/x-gtar - The file in PRICE which is failing.)
file #14724:  TestController2.tgz added by gcasa (5KiB - application/x-gtar - Demonstration project which shows that it's not the connections.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by gcasa (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-01-02 gcasa StatusConfirmed Works For Me
        Open/ClosedOpen Closed
    2008-01-01 gcasa Attached File- Added Convolve55.gorm.tgz, #14731
    2007-12-31 gcasa Attached File- Added TestController2.tgz, #14724
    2007-12-06 gcasa Assigned toNone gcasa
    2007-12-06 FredKiefer StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code