From: Mark DePristo
Subject: GCL hash table bug?
Date: 
Message-ID: <5rejs6$noo@news.acns.nwu.edu>
Hi,

I've written a lisp program for translating Part-of-speech 
tagged text (of the form "TOKEN/TAG").  Convert-tags was 
developed under GCL 2.2, on a Solaris 2.5 SPARC machine. It's 
been in use for about a week now, performing flawlessly with all
of its translation tables (association list that are converted 
into hash-tables) and tagged-texts.  Disturbingly, yesterday 
when I ran the program on a text that needed no translations 
(i.e, the translation table was in development and thus contained 
no entries), GCL seg faulted.

At first I thought this was a product of no run-time error 
checking with compiled code, but the same code seg faulted 
completed out of GCL when running non-compiled lisp code.  
A bit of experimentation set the minimum working translation 
table length at 2 entries.  Tracing and stepping through the
code was no help, as the hash-table was intact up to the seg fault.  

I transferred the program to Allegro Common Lisp 4.1 on a NT 
4.0 machine, and the same code performed perfectly.  As far as 
I can tell, this is a fault of the GCL implementation that I have.

The heart of the translation program is the following function:

(defun translate-tag (tag translation-table)
  (gethash tag translation-table tag))  

Stelle(Cltl2: 438) states that is code is valid. If there is an 
entry for tag in the translation-table, then value(tag) is returned, 
else tag itself is returned.  

Has anyone heard of this problem?  Is this, as I am guessing, a problem
with GCL?

Thanks for any suggestions.

Mark A. DePristo
<··········@nwu.edu>
Northwestern University