[Chicken-users] more: news from the valgrind front - another test case

[Jörg F . Wittenberger]

There is one more - very interesting - occurrence of valgrind
complaints, which point towards some possible (or highly probably
that is) issue.

# Current Situation

I've got a pretty complex program from which I'm trying to derive
test cases.  At this time I see this program run for quite some time.
(Before, when C_a_i_string_to_number reported issues valgrind did quit
after so many messages.  Now I'm watching it run for several seconds
[which would be several hundreds under normal execution].  While this
would cover all sorts of complicated issues there are only four valgrind
complaints.

Those arise both very early in the initialisation process.
(According to -:D logs)

Somewhere in irregex-core.scm.  However this appears to be just the
first case in execution order; nothing special about irregex so far.

# The Test Case

The test case is kind of uncommon.  Sorry.  I can't do better right now.
(Keep in mind: this is not about irregex; more low level.)

There steps ahead:
1. I'll first show that there is no problem at all.  ;-)
2. Insert a stupid display statement, which is supposed to be always #t
3. Receive either #t or #t as output and an valgrind complaint when
  it displays #f

## 1. Proof that the problem is sort of contained:

> From the command line you want to run:

valgrind --log-file=/tmp/csi.vg --track-origins=yes csi

Now follow the file /tmp/csi.vg in another window
to see when valgrind reports errors.

Next wait for the friendly chicken prompt and go on:

(c)2008-2011 The Chicken Team
(c)2000-2007 Felix L. Winkelmann
Version 4.7.4 (custom)
linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
compiled 2011-10-07 on ajax (Linux)

#;1> (use irregex)
; loading /usr/lib/chicken/6/irregex.import.so ...
; loading library irregex ...

At this moment you should *not yet* have an error message.
Everything *seems* fine.
Exit this session.

# 2. Insert Stupid Debug Code

Find irregex-core.scm and insert this code right after
"(define (cset-complement ..."  -- which would be the last
reference to *all-chars*.  Where exactly will probably
not matter at all as long as it if after the "(define *all-chars*":

--cut here---  %< --- %< ---
(display "\n
Now watch the interesting value (should be true):
" (current-error-port))

(display (equal? *all-chars* `(/ ,(integer->char 0) ,(integer->char #xD7FF)
     ,(integer->char #xE000) ,(integer->char #x10FFFF))) 
(current-error-port))

(display "\n
So much for the difference.
\n" (current-error-port))
--cut here---  %< --- %< ---

This would compare *all-chars* to be EQUAL? to a literate copy of its
own definition.

Recompile (best with DEBUGBUILD=1) and retry the test case.

Now watch the interesting value (should be true):
#f
So much for the difference.

## 2b.  Remove valgrind from the test:

address@hidden:~/build/chickenvg$ csi -e '(use irregex)'

Now watch the interesting value (should be true):
#f
So much for the difference.

# 3. Make it Random

Case 2b (debug code plus csi) will reliably print #f (at
least for about 50+ manual tries).  The complex app
you better don't know about will actually run printing
#t in about 70% of startups (and run wild otherwise).



Hrm. ..  I can't find it.


Best Regards

/Jörg