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

[Alan Post]

Given the odd behavior you're experiencing, I would suggest
expanding your test case:

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

Basically, hit every ridiculous but equivalent combination you can
to both reduce the chance you've made a basic mistake and to tease
out any underlying behavior for which the comparison you're doing
might be a surface detail.

-Alan

On Fri, Oct 07, 2011 at 09:58:23PM +0200, Jörg F. Wittenberger wrote:
> 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
> 
> 
> 
> 
> _______________________________________________
> Chicken-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/chicken-users

-- 
.i ma'a lo bradi cu penmi gi'e du