[racket] why a segfault on the command line, but not in DrRacket?

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