[racket] why a segfault on the command line, but not in DrRacket?
It should be safe to use from untyped code. TR inserts contracts to
protect the typed modules' invariants. Of course, there could be bugs
there too.
Could you try removing uses of math/flonum? If the problem persists
without them, we can probably rule out TR-related problems.
Vincent
At Tue, 30 Dec 2014 16:20:15 -0800,
Matthew Butterick wrote:
>
> Yes, I'm using math/flonum (for the first time) within untyped code
> (racket/base). Bad idea?
>
> On Tue, Dec 30, 2014 at 2:47 PM, Vincent St-Amour <stamourv at ccs.neu.edu>
> wrote:
>
> > Do you use Typed Racket, or libraries that use Typed Racket? (math,
> > images, ...)
> >
> > TR's optimizer emits unsafe operations when it can prove that they're
> > actually safe, but there may be bugs there.
> >
> > Vincent
> >
> >
> > At Tue, 30 Dec 2014 12:19:38 -0800,
> > Matthew Butterick wrote:
> > >
> > > No, but the possibility of user error remains with us, always.
> > >
> > > On Tue, Dec 30, 2014 at 12:06 PM, Pierpaolo Bernardi <
> > olopierpa at gmail.com>
> > > wrote:
> > >
> > > > Just for excluding any possibility of user error: do you use any
> > > > unsafe features?
> > > >
> > > > On Tue, Dec 30, 2014 at 8:43 PM, Matthew Butterick <mb at mbtype.com>
> > wrote:
> > > > > No, it's all Racket libraries.
> > > > >
> > > > > OTOH I may be the one causing the memory-management problems. The
> > issues
> > > > are
> > > > > arising in my typesetting program, which passes around some large
> > data
> > > > > structures as function inputs. By "large" I mean a list of 10e5 to
> > 10e6
> > > > > structs, each with its own hashtable. Perhaps this is imprudent. It
> > > > > certainly makes the GC huff and puff (about 25-30% of my running
> > time is
> > > > GC)
> > > > >
> > > > > OTOOH, it does seem to be a command-line peculiarity, because I
> > haven't
> > > > > found a similar limit for DrRacket yet. For instance, I just typeset
> > a
> > > > file
> > > > > with 1.5M characters, resulting in a ~600 page PDF, and it ran fine.
> > > > >
> > > > > When I tried running on the command line with this input, I got a
> > > > different
> > > > > error than before (and within a couple seconds of starting the
> > program):
> > > > >
> > > > > Seg fault (internal error during gc) at 0x10aac0000
> > > > > Bus error: 10 (core dumped)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Dec 30, 2014 at 11:09 AM, Matthew Flatt <mflatt at cs.utah.edu>
> > > > wrote:
> > > > >>
> > > > >> Does your program use any foreign libraries? That behavior sounds
> > > > typical
> > > > >> of memory-management problems.
> > > > >>
> > > > >> > On Dec 30, 2014, at 11:47 AM, Matthew Butterick <mb at mbtype.com>
> > > > wrote:
> > > > >> >
> > > > >> > I have a program that consistently works in DrRacket regardless of
> > > > input
> > > > >> > size.
> > > > >> >
> > > > >> > But on the command line, once input exceeds a certain threshold,
> > the
> > > > >> > program consistently dies with a "Segmentation fault: 11 (core
> > > > dumped)"
> > > > >> > error (though it works with smaller files). I'm invoking `racket`
> > > > without
> > > > >> > any special flags, like so:
> > > > >> >
> > > > >> > racket main.rkt
> > > > >> >
> > > > >> > I know which line of my program is triggering the segfault. But
> > since
> > > > >> > the error is related to the input size and the use of command-line
> > > > Racket, I
> > > > >> > think I ought to look elsewhere for the cause.
> > > > >> >
> > > > >> > Are there particular command-line flags that can be helpful in
> > > > >> > diagnosing segfaults? Is a segfault like this typically due to
> > > > running out
> > > > >> > of memory?
> > > > >> > ____________________
> > > > >> > Racket Users list:
> > > > >> > http://lists.racket-lang.org/users
> > > > >> >
> > > > >
> > > > >
> > > > >
> > > > > ____________________
> > > > > Racket Users list:
> > > > > http://lists.racket-lang.org/users
> > > > >
> > > >
> > >
> > > ____________________
> > > Racket Users list:
> > > http://lists.racket-lang.org/users
> >