Ticket #1794 (closed bug: fixed)

Opened 11 years ago

Last modified 11 years ago

Linear hash scan assumes non-NULL keys

Reported by: nwellnhof Owned by: luben
Priority: normal Milestone:
Component: core Version: trunk
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:


The linear hash iterator macro assumes that all keys in a hash are non-NULL. This can cause all kinds of problems with zero integer keys. For example, the following PIR code crashes on my machine because the hash entry doesn't get marked during GC:

.sub 'main' :main
    .include "hash_key_type.pasm"
    .local pmc hash
    hash = new ['Hash']
    hash = .Hash_key_type_int

    hash[0] = 'foo'

    sweep 1

    $S1 = 'abc'
    $S2 = 'def'

    $S0 = hash[0]
    say $S0

Change History

Changed 11 years ago by luben

  • status changed from new to assigned
  • owner set to luben

There is a fix in r49176. - It does not fix HashIterator PMC though - It does not fix a similar case with cstring keys - It does not fix a similar case with ptr keys

I am leaving it opened for now because the problem needs discussion.

- Do we want NULL keys (different from PMCNULL and STRINGNULL) in parrot hashes - Do we want plain integer keys in parrot hashes? - Do want NULL ptr keys in parrot hashes?

Changed 11 years ago by luben

Next 2 revisions close NULL keys cases for ptrs,cstrings and using HashIterator with NULL keys

Changed 11 years ago by luben

  • status changed from assigned to closed
  • resolution set to fixed

Also the tests that were not passing in hash_thaw and hash_clone are now passing. The bug is resolved.

Note: See TracTickets for help on using tickets.