bug#38041: crypto with gnutls aka nettle (libhogweed) and scm_realloc

I've got an app that links gnutls (for crypto code) which links nettle (libhogweed) with is a GMP-using crypto library which seems like it wanted to call plain-old realloc, and ended up calling scm_realloc instead. Note that nettle does NOT use guile, so there's no plausible way that I know of to

bug#33642: guile-2.9.1 failing to load ~/.guile file!?

There is now an observable difference between saying ``` $ guile /some/file.scm ``` and ``` $ guile scheme@(guile-user)> (load "/some/file.scm") ``` The latter loads `~/.guile` before providing the guile prompt. The former either doesn't load `~/.guile` at all (I didn't check), or loads it only

bug#33641: guile-2.9.1 multi-threading crash

The following bug report is informal, without any simple test, right now. Very reproducible, though. I have a unit test (it passes with guile-2.2) that creates 120 threads and races them as fast as possible, each thread launched from C++, entering guile, and then from guile, calling some wrappered

bug#27234: Followup.

The original bug report failed to explain how to trigger the bug. I think I know of a simple way to trigger the bug, but have not yet created the simple test-case. I believe that the bug can be triggered like so: Create some medium-sized "random" (arbitrary) snippet of guile code. Send it to the

bug#27234: Hang in GC, inf loop while walking frame pointers

what: guile-2.2-stable, from git. I've got a large, complex, heavily multi-threaded guile program that hangs during garbage collection; usually after running for half a day. It hangs in a tight loop in scm_i_vm_mark_stack, spinning at 100% of CPU. This is due to the for-loop line fp = SCM_FRAME_D

bug#26711: Example1 is buggy

Example1.cc is has a work-around -- main() needs to call scm_init_guile() or scm_with_guile(). If this is done, the problem goes away. The problem with example1 is that the first thread to initialize guile is eventually destroyed. However, the first thread to call guile never ever sets "needs_unr

bug#26616: also a bug in guile-2.0.11

I just noticed that this bug DOES reproduce in guile 2.0.11 which is the version that ships with Ubuntu Xenial (Ubuntu 16.04) The above loop took 37 cpu-minutes to execute. The non-parallel version executes instantly (fractions of a cpu-second).

bug#26616: close

Per last message, close.

bug#26616: close

I just retested with a pull from today's git and the problem does NOT reproduce. Attempting to close this bug. tested with $ guile --version guile (GNU Guile) 2.2.2.1-886ac

bug#26616: guile-2.2 par-for-each hangs for large lists

The following spins, burning about 250% cpu time, for large lists; it works fine for smaller lists. This is for a recent version of guile from git: guile -v guile (GNU Guile) 2.1.5.19-7e9395 will retry with newer guile shortly. On fresh guile: (use-modules (srfi srfi-1)) (define al (list-tabu

bug#25397: guile-2.2 regression in utf8 support in scm_puts scm_lfwrite scm_c_put_string

wrote: > On Tue 10 Jan 2017 04:34, Linas Vepstas > writes: > > > void *wrap_puts(void* p) > > { > >char *wtf = p; > > > >SCM port = scm_current_output_port (); > > > >scm_puts("the port-encoding is=", port); > >scm_puts

bug#25498: Crash in open-file; patch attached

Specifically, this crashes, now: GNU Guile 2.1.6.10-710eb On Wed, Feb 15, 2017 at 2:25 AM, Linas Vepstas wrote: > I'm using version 2.1 pulled from git, maybe a few days or week before the > bug was opened. > > On Sat, Feb 11, 2017 at 3:10 PM, Ludovic Courtès wro

bug#25498: Crash in open-file; patch attached

I'm using version 2.1 pulled from git, maybe a few days or week before the bug was opened. On Sat, Feb 11, 2017 at 3:10 PM, Ludovic Courtès wrote: > Hi Linas, > > Linas Vepstas skribis: > > > The following crashes instantly; I used single-quotes by accident. > >

bug#25498: Crash in open-file; patch attached

The following crashes instantly; I used single-quotes by accident. (open-file "/tmp/lg" 'w') Stack: Enter `,help' for help. scheme@(guile-user)> (open-file "/tmp/lg" 'w') Thread 1 "guile" received signal SIGSEGV, Segmentation fault. scm_i_mode_to_open_flags (mode=mode@entry=0x55ac5660,

bug#25387: guile-2.2 multi-thread segfault in SCM_VALIDATE_WEAK_TABLE

Hi Andy: I just code-reviewed, it looks like a good fix; you're saying that the dynamic state was being accidentally collected when it shouldn't have been. Tested, it tests OK, after 40 mins cpu time, its still running. --linas

bug#25386: This can be closed

This can be closed as 'fixed'; I tested on today's git guile (GNU Guile) 2.1.5.19-7e9395 and the worst of it seems to be over. mem usage growth on the original test case: (heap-size . 7921664) (gc-times . 40) (heap-size . 14344192) (gc-times . 953) (heap-size . 14344192) (gc-times . 5219) ; af

bug#25387: better but still an issue.

Retested with today's version of git. still crashes, but not instantly; it now takes 20 seconds to 5 minutes to reproduce. guile (GNU Guile) 2.1.5.19-7e9395

bug#25267: guile-2.2 crash in GC

On Mon, Jan 9, 2017 at 3:53 PM, Andy Wingo wrote: > On Sat 24 Dec 2016 19:43, Linas Vepstas writes: > >> [Switching to Thread 0x7fffc0ff9700 (LWP 3680)] >> thread_mark (addr=0x558f7700, mark_stack_ptr=, >> mark_stack_limit=0x7fffc0ff7c50, env=) >> a

bug#25397: guile-2.2 regression in utf8 support in scm_puts scm_lfwrite scm_c_put_string

g to see this=Hòa Phú Phú Tân the port-encoding is=UTF-8 Was expecting to see this=係 拉 丁 字 母 æ¯ What's cool is that all this stuff works in email! --linas On Mon, Jan 9, 2017 at 4:03 PM, Andy Wingo wrote: > On Sun 08 Jan 2017 19:16, Linas Vepstas writes: > >> There appears t

bug#25386: Please ignore previous stack trace.

Sorry, please ignore the previous stack trace. I updated to version 2.0.13 (manually compiled) and it crashed with a zillion messages: guile: warning: weak hash table corruption (https://bugs.gnu.org/19180) so that's a done deal, then.

bug#25386: calling gc too often triggers a crash

Since above works so swimmingly in the bove example, I tried it in a production system. Calling gc shortly before thread exit results in a crash, always the same crash, always in under 20 minutes: guile: hashtab.c:137: vacuum_weak_hash_table: Assertion `removed <= len' failed. Aborted again, thi

bug#25397: guile-2.2 regression in utf8 support in scm_puts scm_lfwrite scm_c_put_string

There appears to be a regression in guile-2.2 with utf8 handling in the scm_puts() scm_lfwrite() and scm_c_put_string() functions. In guile-2.0, one could give these utf8-encoded strings, and these would display just fine. In 2.2 they get mangled. The source of the mangling seems to be an assump

bug#25386: test case update

Ran the three test case overnight; saw mostly no increase in mem usage. -- gc before every thread exit: up to 9M thread exits, no change in heap-size -- gc before every third thread exit: 25M thread exits, no change. -- gc before every 17th thread exit: 44M thread exits, relatively small increas

bug#25386: Manual gc helps

I did a fairly through review of the thread-creation and thread-join code in the git master branch, and it looks to be just fine. Thus, some experimentation is in order: Going back to guile-2.0, I see this behavior: guile -v guile (GNU Guile) 2.0.11 Packaged by Debian (2.0.11-deb+1-10) If I add a

bug#25387: also crashes in guile-2.0

Also crashes in guile-2.0, but takes much longer - 5 minutes --linas

bug#25387: guile-2.2 multi-thread segfault in SCM_VALIDATE_WEAK_TABLE

Following program crashes immediately (fraction of a second) in guile-2.2, current git version (as of 29 Dec 2016 a0656ad4cf976b3845e9b9663a90b46b4cf9fc5a ) It runs fine in guile-2.0. Its doing something slightly squonky: referencing the variable 'cnt' in a thread. Note definition of use before d

bug#25386: guile-2.0 and 2.2 thread leakage+crash; very simple test attached.

The (very simple) program below leaks ... something, very rapidly, and then crashes after about 15-30 seconds. Last thing printed before crash: rate=194.80519560944032 num threads=2 ((gc-time-taken . 2791348254) (heap-size . 7532883968) (heap-free-size . 2449408) (heap-total-allocated . 239128826

bug#25267: crashes here only for invalid scheme

FYI: important note: this crashes only because an exception path is taken. Due to a "bug" in the shell script above, `ctr` is undefined, so an unbound-variable exception is thrown. When the scheme is valid, then it does NOT crash here! --linas opencog> (NumberNode ctr) Entering scheme shell; us

bug#24446: close - not a bug

Seems to me this bug report can be closed as "not a bug", given the post above. -- linas

bug#25267: guile-2.2 crash in GC

FYI, this is quickly and easily reproducible, happens within seconds, and hits the same spot every time. Note-to-self (not for general consumption): my unit test to provoke this is to start the cogserver and run this shell script: #!/bin/bash i=0 while true ; do let i=$i+1 if [ "$(($i % 2000)

bug#25267: guile-2.2 crash in GC

Merry Christmas! Below is a crash observed in guile-2.2, the git version of 21 December 2016 (last commit 0ce8a9a5e01d3a12d83fea85968e1abb602c9298 Author: Andy Wingo Date: Sun Dec 18 23:00:07 2016 +0100) I do not have any simple test-case to reproduce this (yet?) so this is an FYI bug report.

bug#25238: guile-2.2 threading bug

Merry Christmas! A guile-git threading bug! -- linas $ cat fail.cc // // fail.cc // // This C++ program crashes, when compiled against todays (20 Dec 2016) // guile-2.2 from git. git log says a recent commit is //0ce8a9a5e01d3a12d83fea85968e1abb602c9298 // but I beielve any guile-2.2 versio

bug#19180: guile bug#19180: vacuum_weak_hash_table error

Anand, I've been using guile, straight from git for maybe almost 2 years(??) in a semi-harsh environment (lots of threads, lots of C++ smob jiggery-pokery, entering and exiting guile, redirecting ports, using fluids at the scheme/c++ boundary, catching and throwing exceptions to/from C++, interleav

bug#21221: closed (Re: bug#21221: guile-2.2 socket ports used with display does not send utf8 !)

On Mon, Jun 20, 2016 at 10:56 AM, GNU bug Tracking System < help-debb...@gnu.org> wrote: > (display "Hòa Phú Phú Tân Hiệp An Tương Bình Hiệp Định Hòa\n" sss) Yep, it now works for me with guile-2.1.3 --linas

bug#19676: madvise bug in guile-git

OK. On Tue, Jun 21, 2016 at 2:52 AM, Andy Wingo wrote: > On Tue 21 Jun 2016 01:36, Linas Vepstas writes: > > > On Mon, Jun 20, 2016 at 10:34 AM, Andy Wingo wrote: > > > > On Sat 24 Jan 2015 23:52, Linas Vepstas > > writes: > > > > >

bug#19676: madvise bug in guile-git

On Mon, Jun 20, 2016 at 10:34 AM, Andy Wingo wrote: > On Sat 24 Jan 2015 23:52, Linas Vepstas writes: > > > I've got a test where hit guile with maybe a dozen threads doing > > assorted things. Doing this, I then see handful of these messages: > > "madv

bug#21221: guile-2.2 socket ports used with display does not send utf8 !

ould even be an encoding error, why its not utf8 end-to-end. This is for guile-2.2 from a recent git pull of the master source from about June 2015, but I believe the problem occurs on guile-2.0 as well. guile --version guile (GNU Guile) 2.1.0.305-e7097-dirty this is on ubuntu 14.04 aka ubuntu trusty -- Linas Vepstas

bug#19676: madvise bug in guile-git

Hi, I've got a test where hit guile with maybe a dozen threads doing assorted things. Doing this, I then see handful of these messages: "madvise failed: Cannot allocate memory" every 5 or 10 seconds. Except for the printing, everything seems stable. I've aptured a stack trace for this, below, b

bug#19354: (spawn-server (make-tcp-server-socket doesn't work in current git

After pulling from git, I have observed that the tcp scoket server no longer works. The below used to work fine: $ guile scheme@(guile-user)> (use-modules (system repl server)) scheme@(guile-user)> (use-modules (system repl common)) scheme@(guile-user)> (spawn-server (make-tcp-server-socket #:po

bug#19180: vacuum_weak_hash_table error

Ludovic Courtès gnu.org> writes: > > Could you apply with attached patch (with “patch -p1 < the-patch” run > from the top of the source tree), and report the lines that are printed > before the assertion failure? Not to be stupid, but: I pulled the latest guile from git, went to apply the patch,

bug#19180: vacuum_weak_hash_table error

Anand Mohanadoss gmail.com> writes: > > Hi,We have observed the following error a few times with guile 2.0.11 (32-bit) on x86_64 Linux while processing large binary files (1.5GB+) and comparing messages contained therein.  fish: hashtab.c:137: vacuum_weak_hash_table: Assertion `removed <= len

Re: UTF-8 regression in guile 1.9.5

2009/12/11 Mike Gran : > I think I prefer that the coder take the responsibility of calling > setlocale, but, I only think that because it is how C works.  I'm used > to that convention. > OK works for me. --linas

Re: UTF-8 regression in guile 1.9.5

2009/12/6 Mike Gran : > >> > need to call (setlocale LC_ALL "") > > But for Guile to store characters as codepoints, declaring a locale > pretty much a requirement now. Would it make sense to add (setlocale LC_ALL "") to some default, e.g. boot-9.scm ? --linas

Re: UTF-8 regression in guile 1.9.5

2009/12/6 Mike Gran : >> From: Linas Vepstas > > >> Then, from the guile prompt, I can evaluate the following: >> >>    (new-node "てみました。") >> >> and get the output "The name is てみました。" >> >> >> However, in guile-1.

UTF-8 regression in guile 1.9.5

Hi, I seem to see either a regression in guile-1.9.5 with regard to UTF-8 strings, or at least some sort of incompatible change. In guile-1.8.6, I am able to do the following: SCM new_node (SCM sname) { char * cname = scm_to_locale_string(sname); printf ("The name is %s\n", cname); f

Re: GNU Guile 1.9.5 released (alpha)

2009/11/17 Ludovic Courtès : > We are pleased to announce GNU Guile release 1.9.5. FWIW, it appears that guile-1.9.5 does not work with the default bdw-gc in ubuntu/debian, which is gc-6.8 -- I got the crash below downloading, compiling, installing gc-7.1 seems to fix the problem. BTW, I am vagu

[bug #24867] `define' should be thread-safe

Follow-up Comment #6, bug #24867 (project guile): I've attached a patch to lock the entry and exit to scm_sym2var(). However, it doesn't fix the problem (at all). -- There are still deadlocks in garbage collection, (but different from the previously reported one !?) -- There are still crashes (

[bug #24867] `define' should be thread-safe

Follow-up Comment #5, bug #24867 (project guile): 1) Easier said than done, because: 1a) the mutex needs to be recursive, since sym2var evaluates code in boot9.scm which can cause sym2var to run again. The core problem is that the mechanism for specifying recursive mutexes seems to be somewhat

[bug #24867] `define' should be thread-safe

Follow-up Comment #3, bug #24867 (project guile): Note that the attached test case shows 4 distinct behaviours: 1) runs fine, exiting normally, w/o any errors 2) Spewing messages such as: ERROR: Unbound variable: x2-347 ERROR: Unbound variable: x2-347 ERROR: Unbound variable: x2-347 ERROR: Unbo

[bug #24867] `define' should be thread-safe

Additional Item Attachment, bug #24867 (project guile): File name: define-race.c Size:2 KB ___ Reply to this item at: ___ Message sen

[bug #24867] `define' should be thread-safe

reading the hash tables while they are being updated, and thus may obtain stale/bad data. Signed-off-by: Linas Vepstas --- libguile/modules.c |9 - 1 file changed, 8 insertions(+), 1 deletion(-) Index: guile-1.8.6/libguile/modules.c

Re: [PATCH] Final: thread lock nesting debugging

2008/11/20 Linas Vepstas <[EMAIL PROTECTED]>: > -- The reason for dropping the heap_mutex before grabbing > the other lock (for example scm_i_port_table_mutex), > is somewhat obscure, but at one point I decided that this > was OK, and arguably correct. As I write this, I&

Re: [PATCH] Final: thread lock nesting debugging

2008/11/19 Neil Jerram <[EMAIL PROTECTED]>: > 2008/11/17 Linas Vepstas <[EMAIL PROTECTED]>: >> I've been seeing all sorts of deadlocks in guile, and so I wrote a small >> debugging utility to try to track down the problems. > > Interesting patch! > > On

Re: [PATCH]: deadlock in make_struct()

2008/11/17 Andy Wingo <[EMAIL PROTECTED]>: > Hi Linas, > > I was about to write about how your patch looked incorrect to me, > because GC could see a half-initialized struct (and potentially sweep > it, with a bad free function); Well, I tried to think that through. I tried to find a need for a "r

[PATCH] Final: thread lock nesting debugging

now. This is my "final" version of this patch, I'd sent a beta version a few days ago. Its "final" because I'm not anticipating any further changes. --linas Add a deadlock debugging facility to guile. Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> --

[PATCH]: deadlock in make_struct()

thread 12 -- holding &scm_i_sweep_mutex, sleeping on heap_mutex held in increase_mtrigger() at gc-malloc.c:234 sleeping in scm_i_thread_put_to_sleep() at threads.c:1621 Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> --- libguile/struct.c | 10 -- 1 file ch

Re: Hung threads

Hi, 2008/11/14 Linas Vepstas <[EMAIL PROTECTED]>: > Here's a deadlock I saw today. Here's a different deadlock that is fully debugged. The guilty code leading to the deadlock is in make_struct(), in struct.c circa line 463, which tries to alloc memory while holding a CRITICA

Many, many lock races

I'm now going through guile-1.8.5 code, and see the potential for races leading to deadlocks in many dozens of places. What I's seeing is lots of this: scm_i_scm_pthread_mutex_lock(some_lock) do_something() scm_i_pthread_mutex_unlock(some_lock) With the current set of #defines, this turns into

[PATCH] thread lock nesting debugging

ly to the guile source tree; any suggestions on how it should be organized so that it would be acceptable? Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> --- config.h.in|3 + configure.in | 11 libguile/Makefile.am |2 libguile/deb

Hung threads

Here's a deadlock I saw today. It appears to be a case of improperly-nested locks. Thread 16 is trying to exit. CRITICAL SECTION -- threads 16 scm_i_port_table_mutex -- threads 18,24,27,28,29,30,32,33,37,39 scm_i_sweep_mutex -- threads 19,21, 35, 36, 38 t->heap_mutex -- threads 23 thread_admin_mu

Re: Does anyone actually use threads with guile?

2008/11/13 Andy Wingo <[EMAIL PROTECTED]>: > For my part I apologize for not having the cycles Fine, I'm hacking around it for now, but would like to see something for 1.8.6. > On Thu 13 Nov 2008 05:56, "Linas Vepstas" <[EMAIL PROTECTED]> writes: > >>

[PATCH] fix for Re: crash in gc with upside-down stack

ly in time for guile-1.8.6! Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> --- libguile/threads.c | 19 +-- 1 file changed, 17 insertions(+), 2 deletions(-) Index: guile-1.8.5/libguile/threads.c ===

Re: crash in gc with upside-down stack

2008/11/11 Linas Vepstas <[EMAIL PROTECTED]>: >> >> My stack below. >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0xf5333b90 (LWP 20587)] >> 0xf7711ce3 in scm_mark_locations (x=0xf5333110, n=4294966782) at >>

Re: crash in gc with upside-down stack

Some minor updates: 2008/11/11 Linas Vepstas <[EMAIL PROTECTED]>: > > My stack below. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xf5333b90 (LWP 20587)] > 0xf7711ce3 in scm_mark_locations (x=0xf5333110, n=4294966782) at gc-mark.c:435

Re: Does anyone actually use threads with guile?

2008/11/12 Linas Vepstas <[EMAIL PROTECTED]>: > Today, I got a new crash. I have multiple threads, which > are doing nothing but a bunch of define's, in parallel. > (They're loading scheme code from various files). Studying the code just a little bit more, this looks l

crash in gc with upside-down stack

Here's another one, I'm trying to dig into this: Its more or less the same crash as the one reported at: http://bugs.gentoo.org/228097 and http://www.mail-archive.com/bug-guile@gnu.org/msg04568.html My stack below. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xf53