This service will be undergoing non-disruptive maintenance at 07:20 UTC, 2018-12-14. It is expected to last approximately 30 minutes
Bug 149056 - stack overflow while using mutexes in recursion
Summary: stack overflow while using mutexes in recursion
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: guile (Show other bugs)
(Show other bugs)
Version: 3
Hardware: All Linux
medium
low
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-02-18 10:54 UTC by Paul Osmialowski
Modified: 2015-03-05 01:14 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-02 09:56:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Paul Osmialowski 2005-02-18 10:54:36 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0

Description of problem:
I've started such code:
(define finite-loop (lambda (n m mutex)
    (lock-mutex mutex)
    (cond ((not (= 0 n)) (yield) (display m) (display ", ") (display n) (newline) (unlock-mutex mutex) (finite-loop (- n 1) m mutex)))
    (unlock-mutex mutex)
))

(define thread-error-handler (lambda (tag . args)
    (display tag) (display " ") (display args) (newline)
))

(define thread1 
    (let*
	(
	    (mutex (make-mutex))
	    (thread-function (lambda () (finite-loop 1000000 1 mutex)))
	)
	(cons (call-with-new-thread thread-function thread-error-handler) mutex)
    )
)
(display thread1)
(newline)
(finite-loop 100 2 (cdr thread1))
(join-thread (car thread1))

After a while stack overflow inside of the finite-loop function occurs. When I remove mutex locking/unlocking functions program is working properly.


Version-Release number of selected component (if applicable):
guile-1.6.4-14

How reproducible:
Always

Steps to Reproduce:
1. Create file threads-with-mutex.scm
2. Paste program shown above into that file
3. run: guile -s threads-with-mutex.scm


Actual Results:  After a while you may see something like that:
1, 9012
1, 9011
1, 9010
stack-overflow (#f Stack overflow #f #f)


Expected Results:  Further program execution

Additional info:

The workaround is to use 'do' iteration instead of recursion:
(define finite-loop (lambda (n m mutex)
    (do ((i n (- i 1))) ((= 0 i))
        (lock-mutex mutex)
        (yield)
        (display m) (display " ") (display i) (newline)
        (unlock-mutex mutex)
    )
))
However, iteration is not always a solution! That makes mutexes dangerous to use...

Comment 1 Paul Osmialowski 2005-02-18 11:14:01 UTC
I've just found another workaround. The problem is that mutex should be unlocked
insite the cond expression:
(define finite-loop (lambda (n m mutex)
    (lock-mutex mutex)
    (cond
        ((not (= 0 n))
            (yield)
            (display m) (display ", ") (display n) (newline)
            (unlock-mutex mutex)
            (finite-loop (- n 1) m mutex)
        )
        (else (unlock-mutex mutex))
    )
))
But let someone tell me which scheme rule says that previous code was wrong?!


Comment 2 Phil Knirsch 2005-09-02 09:56:07 UTC
Maybe you get one more mutex for each iteration run and they are possibly put on
the internal guile stack and therefore cause in one case an overflow but not in
the other.

But this is just a wield speculative guess.

I'm closing this bug as it's really most likely something very specific and
internal of guile and should rather be handled and fixed properly by the
upstream folks.

Read ya, Phil


Note You need to log in before you can comment on or make changes to this bug.