bugGNUstep - Bugs: bug #27008, NSNextMapEnumeratorPair() in...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #27008: NSNextMapEnumeratorPair() in NSConcreteMapTable treats C-types as objects

Submitted by:  Niels Grewe <thebeing>
Submitted on:  Fri 10 Jul 2009 10:28:03 PM UTC  
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Invalid
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

Sat 11 Jul 2009 02:56:13 PM UTC, comment #4:

Thank you for adding the comments, it's actually much clearer now why that code is there. It turns out that the code in gnustep-base wasn't responsible for my problem after all. The enumerator was initialized correctly, but the subsequent code (initially written for 32bit archs) wasn't entirely 64bit safe, so the variables began trampling over each other. I guess that the map field was simply overwritten, causing the wrong code path to be selected.
I'm sorry for the confusion, but thank you nonetheless for the clarification!

Cheers,

Niels

Niels Grewe <thebeing>
Project Member
Sat 11 Jul 2009 02:12:06 PM UTC, comment #3:

I think you have misdiagnosed the problem ... but you can be forgiven for doing that since the code is horribly obscure due to the way things were hacked when Apple decided to change map and hash tables when they added new APIs and classes while retaining the old C APIs but suing the same names for both old and new.

I've added some comments to the source code about this ...
If the 'map' field of the enumerator is nil, the enumerator is not a GSIMapEnumerator and contains objects in the locations normally using for the node and bucket.

The thing is, this should really only be the case if you have subclassed the new NSMapTable class and are using an enumerator on that subclass. You may well be doing that, but it would be unusual, so I suspect you aren't.
That would lead me to guess that your NSMapEnumerator is corrupt ... eg an uninitialised variable, but that's pretty much a stab in the dark.

Perhaps you could supply a small test program demonstrating the problem ... then I could have try at running it to reproduce the issue, and examine things under gdb to see what's going wrong.

Richard Frith-Macdonald <CaS>
Project Member
Sat 11 Jul 2009 01:06:32 PM UTC, comment #2:

Additionally, NSEndMapTableEnumeration() will do something similar at line #493.

Niels Grewe <thebeing>
Project Member
Fri 10 Jul 2009 10:31:00 PM UTC, comment #1:

I'm sorry, I meant to say that this happens with svn r28389. Somehow missed that...

Niels Grewe <thebeing>
Project Member
Fri 10 Jul 2009 10:28:03 PM UTC, original submission:

Hello,

I just experienced some wiredness with NSMapTable. NSNextMapEnumeratorPair() seems to fail on lines #870 and 886 of NSConcreteMapTable.m (r. The incriminated lines read:

id k = [(NSEnumerator*)enumerator->node nextObject];

and

value = [(NSMapTable)enumerator->bucket objectForKey: k];

respectively. From what I gather, it doesn't make sense here to treat these as objects ('node' in the _GSIMapEnumerator struct is a GSIMapNode structure and 'bucket' is size_t). My own attempts at fixing this failed because I obviously don't grok GSIMap ;-)

I hope that I've diagnosed the problem correctly. If you need any further information, please ask.

kind regards,

Niels

Niels Grewe <thebeing>
Project Member

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-07-11 CaS StatusNone => Invalid
        Open/ClosedOpen => Closed

    Back to the top


    Powered by Savane 3.3