[racket-dev] Embedding racket in vim

I figured this out. It was that vim was not being compiled with the precise
garbage collection when racket was, and a couple of bugs on the vim
allocation of racket objects. I'll hopefully have a patch soon.


On Mon, Dec 10, 2012 at 10:32 PM, Eric Dobson <eric.n.dobson at gmail.com>wrote:

> +correct vim group.
>
>
>
> On Mon, Dec 10, 2012 at 10:25 PM, Eric Dobson <eric.n.dobson at gmail.com>wrote:
>
>> I have recently installed a version of vim with the mzscheme option
>> enabled. And it sortof works except that some times it segfaults or has
>> other memory corruption issues. So I enabled MZ_GC_CHECK when compiling
>> vim, and now I get the corruption every single time on startup.
>>
>> Here is the output from gdb when running it:
>>
>> GNU gdb 6.3.50-20050815 (Apple version gdb-1820) (Sat Jun 16 02:40:11 UTC
>> 2012)
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you
>> are
>> welcome to change it and/or distribute copies of it under certain
>> conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB.  Type "show warranty" for
>> details.
>> This GDB was configured as "x86_64-apple-darwin"...
>> warning: Unable to read symbols for
>> Racket.framework/Versions/5.3.1.9_3m/Racket (file not found).
>>
>> warning: Unable to read symbols from "Racket" (not yet mapped into
>> memory).
>> Reading symbols for shared libraries .......... done
>>
>> (gdb) run
>> Starting program: /Users/endobson/proj/vim/install/bin/vim
>> Reading symbols for shared libraries
>> ++++.+++++.......................................................................................................................................
>> done
>> Reading symbols for shared libraries . done
>> ?: bad module path
>>   in: #<bad-value>
>>   context...:
>>    standard-module-name-resolver
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_INVALID_ADDRESS at address: 0x00000000000000a0
>> 0x0000000100328d99 in scheme_top_level_do_worker (dyn_state=0x0,
>> k=0x7fff5fbfdd10, eb=1000, new_thread=1606409488) at fun.c:1227
>> 1227            scheme_longjmp(*save, 1);
>> (gdb) bt
>> #0  0x0000000100328d99 in scheme_top_level_do_worker (dyn_state=0x0,
>> k=0x7fff5fbfdd10, eb=1000, new_thread=1606409488) at fun.c:1227
>> #1  0x00000001003ff41e in _module_resolve (modidx=0x103004150,
>> stx=0x103004068, env=0x0, load_it=1) at module.c:3860
>> #2  0x000000010041162a in parse_requires () at schthread.h:376
>> #3  0x00000001004122e4 in do_namespace_require () at module.c:7685
>> #4  0x00000001004123ce in scheme_namespace_require (r=0x103ec8008) at
>> module.c:1316
>> #5  0x00000001001574dd in _mh_execute_header ()
>> #6  0x00000001001585d8 in _mh_execute_header ()
>> #7  0x000000010005bc43 in _mh_execute_header ()
>> #8  0x000000010004ca4a in _mh_execute_header ()
>> #9  0x000000010015f608 in _mh_execute_header ()
>> #10 0x00000001002a6093 in call_with_basic (data=0x103ec8008) at
>> schthread.h:376
>> #11 0x00000001002a64a8 in scheme_main_setup (no_auto_statics=1606414024,
>> _main=0x7fff5fbfe268, argc=6433496, argv=0x7fff5fbfe240) at salloc.c:194
>> #12 0x0000000100161fff in _mh_execute_header ()
>> #13 0x00007fff939eb7e1 in start ()
>> (gdb)
>>
>> I can include more information if you can tell me what is useful.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20121213/16464b0b/attachment.html>