Subject: bug#51264: closed (Re: bug#51264: Calling ‘texi-fragment->stexi’in parallel leads to crashes)

From: [email-masked] (GNU bug Tracking System)
Date: Fri, 22 Oct 2021 11:57:02 +0000

Your bug report

#51264: Calling ‘texi-fragment->stexi’ in parallel leads to crashes

which was filed against the guile package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
51264: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=51264
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#51264: Calling ‘texi-fragment->stexi’ in parallel leads to crashes
From: Ludovic Courtès <[email-masked]>
To: [email-masked]
Date: Fri, 22 Oct 2021 13:56:22 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Ludovic Courtès <[email-masked]> skribis:

> I just stumbled upon this bug (here I use Guix to feed Texinfo strings
> but I suppose we could reduce the test case to be Guix-less.)

Here’s a standalone reproducer:

(use-modules (texinfo)
             (sxml simple)
             (ice-9 threads))

(define sequential? (getenv "SEQUENTIAL"))

(define (for-each/maybe-parallel proc lst)
  (if (pk 'sequential? sequential?)
      (for-each proc lst)
      (n-par-for-each 6 proc lst)))

(setvbuf (current-output-port) 'none)
(for-each/maybe-parallel
 (lambda (str)
   (catch 'parser-error
     (lambda ()
       (texi-fragment->stexi str))
     (lambda args
       (pk 'bah! args '<<>> str)
       (error "failed"))))
 (make-list 5000 "Hello @code{world}, this is @emph{Texinfo}."))

It turned out that (sxml ssax input-parse) would reuse the same global
buffer for each call to ‘next-token’ and ‘next-token-of’ (the Texinfo
parser uses the latter).

Fixed in 3b42b1eb526a85e4fac772e1837046e56e3b9bdc.

Ludo’.

Subject: Calling ‘texi-fragment->stexi’ in parallel leads to crashes
From: Ludovic Courtès <[email-masked]>
To: [email-masked]
Date: Mon, 18 Oct 2021 14:54:18 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Hello!

I just stumbled upon this bug (here I use Guix to feed Texinfo strings
but I suppose we could reduce the test case to be Guix-less.)

Test case:

(use-modules (guix) (gnu) (texinfo)
             (ice-9 threads))

(define sequential? (getenv "SEQUENTIAL"))

(define (for-each/maybe-parallel proc lst)
  (if (pk 'sequential? sequential?)
      (for-each proc lst)
      (n-par-for-each 10 proc lst)))

(for-each/maybe-parallel
 (lambda (package)
   (and=> (package-description package)
          (lambda (str)
            (catch 'parser-error
              (lambda ()
                (texi-fragment->stexi str))
              (lambda args
                (pk 'bah! args)
                (error "failed"))))))
 (fold-packages cons '()))

This code crashes when using ‘n-par-for-each’ but passes when run
sequentially:

--8<---------------cut here---------------start------------->8---
$ guix time-machine --commit=9cda21cf20a5c9bdf97e3a6d6c8f901fc3e4307d -- repl -- bug-texi-parser-parallel.scm

;;; (sequential? #f)

;;; (bah! (parser-error #f "Unknown command" codeand))
In thread:
failed

;;; (bah! (parser-error #f "Unknown command" endm))
In thread:
failed

;;; (bah! (parser-error #f "Unknown command" cod))
In thread:
failed

;;; (bah! (parser-error #f "Unknown command" comm))
In thread:
failed

;;; (bah! (parser-error #f "Unknown command" enum))
In thread:
failed

;;; (bah! (parser-error #f "Unknown command" cod))
In thread:
failed

;;; (bah! (parser-error #f "Unknown command" enem))
In thread:
failed

;;; (bah! (parser-error #f "Unknown command" endmand))
In thread:
failed
;;;;; (bah! (parser-error #f "Unknown command" eomm))
In thread:
failed
$ SEQUENTIAL=y guix time-machine --commit=9cda21cf20a5c9bdf97e3a6d6c8f901fc3e4307d -- repl -- bug-texi-parser-parallel.scm

;;; (sequential? "y")
$ guix repl -- <(echo '(pk (version))')

;;; ("3.0.7")
--8<---------------cut here---------------end--------------->8---

The bits shown in the ‘parser-error’ arguments suggests memory
corruption.

Ludo’.