<div dir="ltr">No, but the possibility of user error remains with us, always.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 30, 2014 at 12:06 PM, Pierpaolo Bernardi <span dir="ltr"><<a href="mailto:olopierpa@gmail.com" target="_blank">olopierpa@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just for excluding any possibility of user error: do you use any<br>
unsafe features?<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Dec 30, 2014 at 8:43 PM, Matthew Butterick <<a href="mailto:mb@mbtype.com">mb@mbtype.com</a>> wrote:<br>
> No, it's all Racket libraries.<br>
><br>
> OTOH I may be the one causing the memory-management problems. The issues are<br>
> arising in my typesetting program, which passes around some large data<br>
> structures as function inputs. By "large" I mean a list of 10e5 to 10e6<br>
> structs, each with its own hashtable. Perhaps this is imprudent. It<br>
> certainly makes the GC huff and puff (about 25-30% of my running time is GC)<br>
><br>
> OTOOH, it does seem to be a command-line peculiarity, because I haven't<br>
> found a similar limit for DrRacket yet. For instance, I just typeset a file<br>
> with 1.5M characters, resulting in a ~600 page PDF, and it ran fine.<br>
><br>
> When I tried running on the command line with this input, I got a different<br>
> error than before (and within a couple seconds of starting the program):<br>
><br>
> Seg fault (internal error during gc) at 0x10aac0000<br>
> Bus error: 10 (core dumped)<br>
><br>
><br>
><br>
><br>
> On Tue, Dec 30, 2014 at 11:09 AM, Matthew Flatt <<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>> wrote:<br>
>><br>
>> Does your program use any foreign libraries? That behavior sounds typical<br>
>> of memory-management problems.<br>
>><br>
>> > On Dec 30, 2014, at 11:47 AM, Matthew Butterick <<a href="mailto:mb@mbtype.com">mb@mbtype.com</a>> wrote:<br>
>> ><br>
>> > I have a program that consistently works in DrRacket regardless of input<br>
>> > size.<br>
>> ><br>
>> > But on the command line, once input exceeds a certain threshold, the<br>
>> > program consistently dies with a "Segmentation fault: 11 (core dumped)"<br>
>> > error (though it works with smaller files). I'm invoking `racket` without<br>
>> > any special flags, like so:<br>
>> ><br>
>> > racket main.rkt<br>
>> ><br>
>> > I know which line of my program is triggering the segfault. But since<br>
>> > the error is related to the input size and the use of command-line Racket, I<br>
>> > think I ought to look elsewhere for the cause.<br>
>> ><br>
>> > Are there particular command-line flags that can be helpful in<br>
>> > diagnosing segfaults? Is a segfault like this typically due to running out<br>
>> > of memory?<br>
>> > ____________________<br>
>> >  Racket Users list:<br>
>> >  <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
>> ><br>
><br>
><br>
><br>
> ____________________<br>
>   Racket Users list:<br>
>   <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
><br>
</div></div></blockquote></div><br></div>