Re: [racket-dev] build memory use (was: internal error during gc)
Matthew Flatt wrote: We've so far cut the peak memory use of a build by about 1/4 compared to a v6.1.1 build. Yes, peak memory use for me has now dropped from about 900MB to just below 700MB. Veeery nice :-) Philippe _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] internal error during gc
Juan Francisco Cantero Hurtado wrote: Sincerely, I don't know if the bug is in racket or in openbsd. Okay... Well, is anyone interested in trying to locate the cause of the problem? I can recompile the GC with debugging options turned on, etc., if more information is needed, but I don't know how the GC's code actually works and I don't have the time to dive into that... Philippe _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] internal error during gc
Juan Francisco Cantero Hurtado wrote: Works fine on my machine. I've re-built the whole thing several times over the past few days and it does not fail every time. It has failed once out of the last three builds I did. Try with ulimit -d 100. My limit was already set at 1048576 :-) The racket process never reaches that size anyway. Here are two graphs showing the size of the process over time, for two different successful builds: http://www.ccs.neu.edu/home/meunier/chart1.pdf http://www.ccs.neu.edu/home/meunier/chart2.pdf There's one data point every second. The top and right edges of the graphs are the 1048576 KB limit. The maximum size reached (in the second build) was 900116 KB. Interestingly, even tough these two builds succeeded and finished normally, I noticed that they both gave this error message: raco setup: rendering: pkgs/images-doc/images/scribblings/images.scrbl unmap failed: 814000, 278528, 22 raco setup: rendering: pkgs/racket-doc/scribblings/inside/inside.scrbl In both builds the racket process was about 630 MB in size at the time this error message showed up. The place where this error message showed up is the exact same place in the build where racket failed in my original email... Now here is a graph for a build that failed: http://www.ccs.neu.edu/home/meunier/chart3.pdf It failed again while processing images.scrbl, but during the running part of the build this time, not the rendering part: raco setup: running: pkgs/images-doc/images/scribblings/images.scrbl Seg fault (internal error during gc) at 0xd98004 *** Signal SIGABRT in . (Makefile:62 'plain-in-place') *** Error 1 in /home/meunier/lang/racket.new (Makefile:44 'in-place') The running: pkgs/.../images.scrbl is always the point in the build where the racket process reaches its maximum size (883864 KB in this case), but the process was already back down to about 584 MB when the internal error during gc message showed up. Here is the backtrace from gdb on the core file: (gdb) bt #0 0x04a78b01 in kill () at stdin:2 #1 0x04ae37f6 in raise (s=6) at /usr/src/lib/libc/gen/raise.c:39 #2 0x04ae3740 in abort () at /usr/src/lib/libc/stdlib/abort.c:53 #3 0x16e9fc3c in fault_handler () from /home/meunier/lang/racket.new/racket/bin/racket #4 signal handler called #5 memcpy () at /usr/src/lib/libc/arch/i386/string/bcopy.S:66 #6 0x16ea64b9 in GC_mark2 () from /home/meunier/lang/racket.new/racket/bin/racket #7 0x16e7de1f in scheme_register_traversers () from /home/meunier/lang/racket.new/racket/bin/racket #8 0x16ea6b54 in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket #9 0x16ea6c5d in GC_mark_variable_stack () from /home/meunier/lang/racket.new/racket/bin/racket #10 0x16ea37a6 in GC_register_new_thread () from /home/meunier/lang/racket.new/racket/bin/racket #11 0x16ea5df4 in GC_dump () from /home/meunier/lang/racket.new/racket/bin/racket #12 0x16ea83ca in GC_malloc_atomic () from /home/meunier/lang/racket.new/racket/bin/racket #13 0x16ce7649 in scheme_generate_alloc_retry () from /home/meunier/lang/racket.new/racket/bin/racket #14 0x00236c9b in ?? () #15 0x in ?? () Philippe _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] internal error during gc
Juan Francisco Cantero Hurtado wrote: Hi, OpenBSD -current or -stable? amd64 or i386? Stable i386. Philippe _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] How to translate DrRacket GUI to another (human) language?
Jay McCarthy wrote: I also believe (and Robby can confirm this) that any string translations you leave out will just remain in English, even if you don't include them in your constants file. Yes. See also http://docs.racket-lang.org/string-constants/index.html#%28part._.Adding_.String_.Constants%29 There's also a (very low traffic) mailing list for translators: http://lists.racket-lang.org/translators/ You can subscribe to this mailing list if you want to be kept up to date with changes made to english-string-constants.rkt. Note that these translation files only cover the DrRacket GUI and some of the tools, not error messages that result from evaluating code. Philippe _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Apple today
Matthias Felleisen wrote: I should keep it around as a bad example. Speaking of bad examples, here's another one I randomly heard about today. It's about some floating point function written in C that didn't compute the correct result in some cases. When some people tried to figure out the reason for the problem, they found the following comment in the code: The double case was intentionally left broken as an optimization The original sentence is in the first paragraph, here: http://svnweb.freebsd.org/base/head/lib/msun/src/math_private.h?revision=240827view=markup Philippe _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket segfaults during raco setup on OpenBSD
Philippe Meunier wrote: I just tried it and it failed the same way as before. I'll install the devel/libffi package tomorrow and see how that goes. It turns out that devel/libffi was already installed on my computer (as a dependency of other stuff I had installed before) but it was still an old version from February, before the bug in it was fixed. So I just ran configure with --disable-libffi and after that raco setup was able to make pkgs/drracket/gui-debugger without problem. So the patch seems to work. Now raco setup just crashes later: raco setup: making: pkgs/racket-test/tests/racket/stress raco setup: in pkgs/racket-test/tests/racket/stress *** Signal SIGILL in . (Makefile:53 'plain-in-place') *** Error 1 in /home/meunier/lang/plt (Makefile:41 'in-place') GDB gives: (gdb) bt #0 0x1c06d3c0 in scheme_eqv_hash_key2 () #1 0x1c06e2bb in scheme_equal_hash_key () #2 0x1c06e4ba in scheme_hash_tree_get () #3 0x1c06e66c in scheme_hash_tree_equal_rec () #4 0x1c023ee8 in scheme_eqv () #5 0x1c024601 in scheme_equal () #6 0x1c0c9bc8 in scheme_hash_table_iterate_start () #7 0x1c06eaa5 in scheme_hash_key () #8 0x1c06f1af in scheme_bucket_or_null_from_table () #9 0x1c06f1e0 in scheme_bucket_from_table () #10 0x1c1b231c in scheme_stx_phase_shift_as_rename () #11 0x1c1bea6c in scheme_stx_extract_marks () #12 0x1c1c51b7 in scheme_syntax_to_datum () #13 0x1c1c549a in scheme_stx_module_eq3 () #14 0x1c1c5610 in scheme_stx_module_eq3 () #15 0x03ac2f9c in ?? () #16 0x8044497c in ?? () #17 0x8044497c in ?? () #18 0xcf7fe7ac in ?? () #19 0xcf7fe790 in ?? () #20 0xcf7fe784 in ?? () #21 0x01f13b76 in ?? () #22 0x0030 in ?? () #23 0x in ?? () (gdb) Philippe _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] racket segfaults during raco setup on OpenBSD
Matthew Flatt wrote: Thanks! The pull request is now merged. I just tried it and it failed the same way as before. I'll install the devel/libffi package tomorrow and see how that goes. Philippe _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] racket segfaults during raco setup on OpenBSD
Hello, Starting from a clean clone of the git repository, racket3m segfaults on OpenBSD 5.3 while in the middle of doing the raco setup: $ pwd /home/meunier/lang/plt $ make [...] Adding xrepl-test* as pkgs/xrepl-pkgs/xrepl-test Writing racket/etc/config.rktd racket/bin/racket -N raco -l- raco setup raco setup: version: 5.90.0.9 [3m] raco setup: installation name: development raco setup: variants: 3m raco setup: main collects: /home/meunier/lang/plt/racket/collects [...] raco setup: making: pkgs/drracket/gui-debugger raco setup: in pkgs/drracket/gui-debugger Seg fault (internal error) at 0xa866246 *** Signal SIGABRT in . (Makefile:53 'plain-in-place') *** Error 1 in /home/meunier/lang/plt (Makefile:41 'in-place') GDB gives: $ gdb racket/bin/racket racket.core [...] (gdb) bt #0 0x0341bc2d in kill () at stdin:2 #1 0x03487826 in raise (s=6) at /usr/src/lib/libc/gen/raise.c:39 #2 0x0348774c in abort () at /usr/src/lib/libc/stdlib/abort.c:70 #3 0x1c1fb8b5 in fault_handler () #4 signal handler called #5 0x0a866246 in sse2_composite_over_n_8_ () from /usr/X11R6/lib/libpixman-1.so.28.0 #6 0x0a844c41 in pixman_composite_glyphs_no_mask () from /usr/X11R6/lib/libpixman-1.so.28.0 #7 0x1001bb48 in composite_glyphs () from /usr/local/lib/libcairo.so.12.1 #8 0x10064978 in composite_glyphs () from /usr/local/lib/libcairo.so.12.1 #9 0x100662ea in clip_and_composite () from /usr/local/lib/libcairo.so.12.1 #10 0x100665b3 in _cairo_traps_compositor_glyphs () from /usr/local/lib/libcairo.so.12.1 #11 0x1000da12 in _cairo_compositor_glyphs () from /usr/local/lib/libcairo.so.12.1 #12 0x1001fed5 in _cairo_image_surface_glyphs () from /usr/local/lib/libcairo.so.12.1 #13 0x100551d2 in _cairo_surface_show_text_glyphs () from /usr/local/lib/libcairo.so.12.1 #14 0x100164ca in _cairo_gstate_show_text_glyphs () from /usr/local/lib/libcairo.so.12.1 #15 0x1000727e in cairo_show_glyphs () from /usr/local/lib/libcairo.so.12.1 #16 0x0846b419 in pango_cairo_renderer_show_text_glyphs () from /usr/local/lib/libpangocairo-1.0.so.3200.0 #17 0x0846b815 in pango_cairo_renderer_draw_glyphs () from /usr/local/lib/libpangocairo-1.0.so.3200.0 #18 0x0ea2204a in pango_renderer_draw_glyphs () from /usr/local/lib/libpango-1.0.so.3200.0 #19 0x0ea2215d in pango_renderer_draw_glyph_item () from /usr/local/lib/libpango-1.0.so.3200.0 #20 0x0ea2280a in pango_renderer_draw_layout_line () from /usr/local/lib/libpango-1.0.so.3200.0 #21 0x0846a028 in _pango_cairo_do_layout_line () from /usr/local/lib/libpangocairo-1.0.so.3200.0 #22 0x08090d73 in ffi_call_SYSV () from /usr/local/lib/libffi.so.0.0 #23 0x08090b7a in ffi_call (cif=0x7e8134a0, fn=0x7d415c20, rvalue=0xcfbe2cf0, avalue=0xcfbe2cb0) at src/x86/ffi.c:326 #24 0x1c1eeb8a in do_ptr_finalizer () #25 0x1c1eedb1 in do_ptr_finalizer () #26 0x033243f2 in ?? () #27 0x0002 in ?? () #28 0x81610754 in ?? () #29 0x89d764a0 in ?? () #30 0xcfbe2d98 in ?? () #31 0x0c4e30ef in ?? () #32 0x8162dc30 in ?? () #33 0x0c4e4074 in ?? () #34 0x in ?? () (gdb) Philippe _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] proposal for moving to packages
Jay McCarthy wrote: If you have the source, then you need all the phase = 1 dependencies, but if you just have the binary then you only need the phase = 0 deps. That's assuming that you want to run the source, but I think that the people who are arguing about still having the source available in the distribution are mostly interested in reading the source, in which case having only the source for the phase = 0 dependencies would probably be a good enough approximation... Philippe _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] new logo
How about combining the ideas of http://i.imgur.com/PuGTE.png http://nxg.me.uk/temp/lambda-r.png (the one in the upper right) and http://tmp.barzilay.org/cr.png (forgetting about an explicit parenthesis) into a single, simple, new symbol like the one attached? (okay, it looks more like a lambda merged with a P rather than with an R but I think the trick would just be to find a font where lambdas and italic Rs combine more nicely than in my quick example). For some reason it slightly reminds me of a symbol for some religious cult or political party, which might or might not be a good thing. And that's all I'll say on the topic... Goodnight. Philippe attachment: lamket.jpg_ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] up-to-date libgtk for drracket on debian stable?
Matthew Flatt wrote: If you configure with `--enable-pthreads', does it fix the problem? If so, we can make `--enable-pthreads' the default for OpenBSD. --enable-pthread Yes, it works. Note that I still get a warning when running configure: [...] === configuring in foreign/libffi (/home/meunier/lang/plt/src/build/foreign/libffi) configure: running /bin/sh ../../../foreign/libffi/configure '--prefix=/home/meunier/lang/plt' '--enable-pthread' --cache-file=/dev/null --srcdir=../../../foreign/li bffi configure: WARNING: unrecognized options: --enable-pthread but otherwise it works fine. Interestingly, the errors I also used to get from drracket about saving preferences are now all gone too, though I don't know whether it's directly related or not. Anyway, thanks a lot! Philippe _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] up-to-date libgtk for drracket on debian stable?
Matthew Flatt wrote: The main change seems to be dropping the 0 version. Does replacing '(0) with '(0 ) also work, so that a versionless name is tried when the versioned name fails? That part seems to work. See the error message below. It looks a bit strange though because the error message from ffi-lib points to libcairo.so.2 when in fact the library that ffi-lib ends up trying to load is libcairo.so.11.0. Just to make things more annoying, libcairo needs libpthread: [...] so I also had to change the define-runtime-lib macro from collects/racket/draw/private/libs.rkt so that the unix case of the macro accepts multiple libraries. I'm not sure that's the best way to go about adding libpthread though, and I'm definitely not sure that my simple change to collects/racket/draw/unsafe/cairo.rkt to add libpthread works on other platforms... Won't libpthread get loaded auomatically when libcairo is loaded? Apparently not: $ ldd /usr/local/lib/libcairo.so.11.0 | grep pthread 0318a000 2318e000 rlib 011 0 /usr/X11R6/lib/libpthread-stubs.so.1.0 $ So it looks like it has to be done explicitely. This is what currently happens with the latest version (without any of my patches): $ gracket/gracket3m gracket/gracket3m:/usr/local/lib/libcairo.so.11.0: undefined symbol 'pthread_mutexattr_destroy' gracket/gracket3m:/usr/local/lib/libcairo.so.11.0: undefined symbol 'pthread_mutexattr_settype' gracket/gracket3m:/usr/local/lib/libcairo.so.11.0: undefined symbol 'pthread_mutexattr_init' ffi-lib: couldn't open libcairo.so.2 (File not found) === context === /home/meunier/lang/plt/collects/racket/draw/unsafe/cairo.rkt: [running body] /home/meunier/lang/plt/collects/racket/draw/private/font.rkt: [traversing imports] /home/meunier/lang/plt/collects/racket/draw/private/post-script-dc.rkt: [traversing imports] /home/meunier/lang/plt/collects/racket/draw.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/private/kernel.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/private/const.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/private/check.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/mred.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/main.rkt: [traversing imports] /home/meunier/lang/plt/collects/scheme/gui/base.rkt: [traversing imports] /home/meunier/lang/plt/collects/scheme/gui.rkt: [traversing imports] /home/meunier/lang/plt/collects/racket/gui/init.rkt: [traversing imports] /home/meunier/lang/plt/collects/scheme/gui/init.rkt: [traversing imports] gracket/gracket3m:/usr/local/lib/libgthread-2.0.so.2600.0: undefined symbol 'pthread_mutex_lock' gracket/gracket3m:/usr/local/lib/libgthread-2.0.so.2600.0: undefined symbol 'pthread_mutex_unlock' gracket/gracket3m:/usr/local/lib/libgthread-2.0.so.2600.0: undefined symbol 'pthread_cond_signal' [... 20 more lines like this ...] gracket/gracket3m:/usr/local/lib/libgthread-2.0.so.2600.0: undefined symbol 'pthread_attr_getschedparam' gracket/gracket3m:/usr/local/lib/libgthread-2.0.so.2600.0: undefined symbol 'pthread_setspecific' link: reference (phase 0) to a variable in module /home/meunier/lang/plt/collects/racket/draw/unsafe/cairo.rkt that is uninitialized (phase level 0); reference appears in module: /home/meunier/lang/plt/collects/racket/draw/unsafe/pango.rkt in: _cairo_t === context === /home/meunier/lang/plt/collects/racket/draw/unsafe/pango.rkt: [running body] /home/meunier/lang/plt/collects/racket/draw/private/font.rkt: [traversing imports] /home/meunier/lang/plt/collects/racket/draw/private/post-script-dc.rkt: [traversing imports] /home/meunier/lang/plt/collects/racket/draw.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/private/kernel.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/private/const.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/private/check.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/mred.rkt: [traversing imports] Philippe _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] up-to-date libgtk for drracket on debian stable?
John Clements wrote: Debian is a slow-moving distribution, and it looks to me like the version of libgtk in the stable version of Debian Lenny isn't new enough for DrRacket. Here's what I get on startup: On a related note, I just tried to compile DrRacket on a week-old OpenBSD 4.8-current and got the following error when starting drracket: ffi-lib: couldn't open libcairo.so.2 (File not found) === context === /home/meunier/lang/plt/collects/racket/draw/unsafe/cairo.rkt: [running body] /home/meunier/lang/plt/collects/racket/draw/private/font.rkt: [traversing imports] /home/meunier/lang/plt/collects/racket/draw/private/post-script-dc.rkt: [traversing imports] /home/meunier/lang/plt/collects/racket/draw.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/private/kernel.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/private/const.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/private/check.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/mred.rkt: [traversing imports] /home/meunier/lang/plt/collects/mred/main.rkt: [traversing imports] /home/meunier/lang/plt/collects/scheme/gui/base.rkt: [traversing imports] /home/meunier/lang/plt/collects/scheme/gui.rkt: [traversing imports] /home/meunier/lang/plt/collects/racket/gui/init.rkt: [traversing imports] /home/meunier/lang/plt/collects/scheme/gui/init.rkt: [traversing imports] (the same error also shows up here and there during the setup phase of the build) I had to change a bunch of files in collects/racket/draw/unsafe to get it to work (see the attached diff). For reference, on OpenBSD the library versions are currently as follows: libcairo.so.11.0 libglib-2.0.so.2600.0 libgmodule-2.0.so.2600.0 libgobject-2.0.so.2600.0 libjpeg.so.64.0 libpango-1.0.so.1802.0 libpangocairo-1.0.so.1802.0 libpng.so.10.0 libgdk-x11-2.0.so.2200.0 libgdk_pixbuf-2.0.so.2200.0 libgtk-x11-2.0.so.2200.0 Just to make things more annoying, libcairo needs libpthread: $ nm /usr/local/lib/libcairo.so.11.0 | egrep -i pthread U pthread_mutex_destroy U pthread_mutex_init U pthread_mutex_lock U pthread_mutex_unlock U pthread_mutexattr_destroy U pthread_mutexattr_init U pthread_mutexattr_settype $ so I also had to change the define-runtime-lib macro from collects/racket/draw/private/libs.rkt so that the unix case of the macro accepts multiple libraries. I'm not sure that's the best way to go about adding libpthread though, and I'm definitely not sure that my simple change to collects/racket/draw/unsafe/cairo.rkt to add libpthread works on other platforms... For reference, the current version of libpthread on OpenBSD is libpthread.so.13.1. With theses changes I was able to run drracket, except that: - I got the following error at startup while the steep tool is being loaded: Error invoking tool #path:/home/meunier/lang/plt/collects/stepper;(stepper+xml-tool.ss) xml-box: bitmap scheme-box.jpg failed to load === context === /home/meunier/lang/plt/collects/drracket/private/tools-drs.rkt:96:0: invoke-drs-tool /home/meunier/lang/plt/collects/drracket/drracket.rkt: [running body] (I have no problem looking at the jpg file using xv or gimp) - at startup I also got a good half dozen popup windows with error messages about preference files. These were gray popup windows with a triangular red-white icon with a black question mark in it. I tried to use the copy message mouse menu of these popup windows but it didn't work. One popup window was different though (it seemed to use a text% editor rather than being just a basic frame with a gray background, and had a round red-white no entry icon) so I could copy from it the error message (which was similar to all the previous ones, and was also printed to the console): copy-file: read or write failed; cannot copy: /home/meunier/.racket/racket-prefs.rktd to: /home/meunier/.racket/TMPPREF12938920161293892016827 === context === /home/meunier/lang/plt/collects/racket/file.rkt:249:10 /home/meunier/lang/plt/collects/framework/splash.rkt:172:0: close-splash /home/meunier/lang/plt/collects/drracket/private/drracket-normal.rkt: [running body] /home/meunier/lang/plt/collects/drracket/drracket.rkt: [running body] internal error: wrong eventspace for constrained event handling /home/meunier/lang/plt/collects/mred/private/wx/common/freeze.rkt:9:0 internal-error /home/meunier/lang/plt/collects/mred/private/wx/common/freeze.rkt:36:0 constrained-reply /home/meunier/lang/plt/collects/mred/private/wx/gtk/queue.rkt:184:31 /home/meunier/lang/plt/collects/ffi/unsafe/try-atomic.rkt:32:0 call-as-nonatomic-retry-point /home/meunier/lang/plt/collects/mred/private/wx/common/queue.rkt:374:7 /home/meunier/lang/plt/collects/mred/private/wx/common/queue.rkt:409:32 internal error: wrong eventspace for constrained event handling /home/meunier/lang/plt/collects/mred/private/wx/common/freeze.rkt:9:0 internal-error
