Opened 17 years ago

Closed 17 years ago

Last modified 3 years ago

#8 closed bug (Fixed)

Regex failure

Reported by: xoltar Owned by: simonmar
Priority: normal Milestone:
Component: hslibs/text Version: 5.02
Keywords: Cc:
Operating System: Architecture:
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


Working through samples from the Great Computer
Language Shootout, I wrote a Haskell program which is
supposed to be basically equivalent to the perl program at:

And in fact I copied the regular expression directly
from the perl example and used search and replace to
change single backslashes to double backslashes to deal
with Haskell vs. Perl strings.

But the regex fails to match where it should. Since I
copied the regex directly from the working perl script,
I'm pretty sure it's correct. Since the RegexString
modules says the regex syntax is that of Perl, I'm
reporting it as a bug.

The haskell file is attached. It is intended to be run
with an integer command line argument (2 is fine), and
input piped from the file at:

I'm on Windows NT 4.0 sp4 and GHC 5.02.

Attachments (1)

regexmatch.8.hs (1.6 KB) - added by xoltar 17 years ago.

Download all attachments as: .zip

Change History (4)

Changed 17 years ago by xoltar

Attachment: regexmatch.8.hs added

comment:1 Changed 17 years ago by simonmar

Status: assignedclosed
Logged In: YES 

The documentation is incorrect to say that the syntax is 
that of Perl, although it may have been right at the time 
of writing.  The regex library doesn't implement Perl's 
special regex extensions (i.e. the (?...) syntax).  I'll 
update the docs to say this.

comment:2 Changed 7 years ago by karel.gardas@…

commit 5cf87b43993f5fd2884755cd16268c2f40572026

Author: Karel Gardas <>
Date:   Thu Jul 14 22:21:09 2011 +0200

    disable for now ARM specific target data layout and triple
    This patch disables ARM specific target data layout and triple.
    The reason for this is that LLVM asserts on some files if this
    is in use. The assert looks:
    Formal argument #8 has unhandled type i32UNREACHABLE executed at

 compiler/llvmGen/LlvmCodeGen/Ppr.hs |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

comment:3 Changed 3 years ago by Sergei Trofimovich <siarheit@…>

In 74897dec/ghc:

Make rts/ThreadLabels.c threadsafe for debug runtime.

rts/ThreadLabels.c has a global hashtable for each
running haskell thread. It's not synchronized across
OS threads.

Was discovered when ran -debug build of ghc itself as:

    $ ghc-stage2 -j8 +RTS -A256M -l

and glibc detected double-free corruption:

    #2  in __libc_message (do_abort=do_abort@entry=2,
        fmt=fmt@entry=0x7fe0bcebf368 "*** Error in `%s': %s: 0x%s ***\n")
    #3  in malloc_printerr (action=3, str=0x7fe0bcebf4c0 "double free or corruption (fasttop)",
        ptr=<optimized out>)
    #4  in _int_free (av=<optimized out>, p=<optimized out>, have_lock=0)
    #5  in stgFree (p=0x7fe060001820) at rts/RtsUtils.c:108
    #6  in freeHashTable (table=0x5929320, freeDataFun=0x36374df <stgFree>) at rts/Hash.c:360
    #7  in freeThreadLabelTable () at rts/ThreadLabels.c:37
    #8  in hs_exit_ (wait_foreign=rtsFalse) at rts/RtsStartup.c:403
    #9  in shutdownHaskellAndExit (n=0, fastExit=0) at rts/RtsStartup.c:481
    #10 in hs_main (...) at rts/RtsMain.c:91
    #11 in main (...) at ghc/hschooks.c:63

Exposed itself after commit:

> commit f6866824ce5cdf5359f0cad78c49d65f6d43af12
> Author: Sergei Trofimovich <>
> Date:   Mon Aug 4 08:10:33 2014 -0500
>     ghc --make: add nicer names to RTS threads (threaded IO manager, make workers)

Signed-off-by: Sergei Trofimovich <>

Reviewers: austin, simonmar, ezyang, bgamari

Reviewed By: ezyang, bgamari

Subscribers: thomie

Differential Revision:
Note: See TracTickets for help on using tickets.