@INVALIDNOREPLY: "URL:
  <<url>
                 Summary: NSNextMapEnumeratorPair() in NSConcreteMapTable
treats C-types as objects
                 Project: GNUstep
            Submitted by: thebeing
            Submitted on: Fr 10 Jul 2009 22:28:03 GMT
                Category: None
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
    _______________________________________________________
Details:
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
    _______________________________________________________
Reply to this item at:
  <<url>
_______________________________________________
  Nachricht geschickt von/durch Savannah
  <url>"
    @INVALIDNOREPLY: "Follow-up Comment #1, bug #27008 (project gnustep):
I'm sorry, I meant to say that this happens with svn r28389. Somehow missed
that...
    _______________________________________________________
Reply to this item at:
  <<url>
_______________________________________________
  Nachricht geschickt von/durch Savannah
  <url>"
    @INVALIDNOREPLY: "Follow-up Comment #2, bug #27008 (project gnustep):
Additionally, NSEndMapTableEnumeration() will do something similar at line
#493.
    _______________________________________________________
Reply to this item at:
  <<url>
_______________________________________________
  Nachricht geschickt von/durch Savannah
  <url>"
    @INVALIDNOREPLY: "Follow-up Comment #3, bug #27008 (project gnustep):
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.
    _______________________________________________________
Reply to this item at:
  <<url>
_______________________________________________
  Message sent via/by Savannah
  <url>"
    @INVALIDNOREPLY: "Follow-up Comment #4, bug #27008 (project gnustep):
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
    _______________________________________________________
Reply to this item at:
  <<url>
_______________________________________________
  Nachricht geschickt von/durch Savannah
  <url>"
    @INVALIDNOREPLY: "Update of bug #27008 (project gnustep):
                  Status:                    None => Invalid                
             Open/Closed:                    Open => Closed                 
    _______________________________________________________
Reply to this item at:
  <<url>
_______________________________________________
  Message sent via/by Savannah
  <url>"
{'source': 'USENET', 'other_information': '{"reply_count": 5, "forum_name": "gnu.gnustep.bug.20140404.mbox"}', 'file': 'data/output/usenet-gnu.gnustep.parquet'}