Charles Campbell wrote:
[email protected] wrote:
Comment #4 on issue 230 by [email protected]: "Vim: Caught deadly
signal SEGV"
http://code.google.com/p/vim/issues/detail?id=230
The errors in the libfontconfig.so look like a library problem:
reading 4 bytes where there are only 2. Because of alignment this
probably does not cause a crash.
The error below update_screen() is most likely what causes the
crash. Can't see what happens there from this info though.
I tried this problem out: gvim -u junk.vim -U NONE macos (where
"junk.vim" has the two lines the poster mentioned)
* used binary compiled from an older machine: gvim -u junk.vim -U NONE
macos
- got a crash and no status line
- gdb doesn't track gvim after gvim "separates" from the console
(ie. becomes its own process)
- binary wasn't compiled for debugging and was stripped
* recompiled vim for debugging and no stripping
- no crash, has status line
- valgrind reported no problems
I'm going to go and update with the new patches now...
Chip
OK, I attached to the gvim, moved the cursor about a bit, and got...
(some of my comments are interlaced)
Program received signal SIGSEGV, Segmentation fault.
0x000000000058a2c1 in char_needs_redraw (off_from=2241, off_to=5439488,
cols=14) at screen.c:5487
5487 && ((ScreenLines[off_from] != ScreenLines[off_to]
---------------------------------------------------------------------
That off_to looks suspicious, as there are only 4245 characters in the
file I'm using...
---------------------------------------------------------------------
(gdb) up
#1 0x000000000058a699 in screen_line (row=26, coloff=0, endcol=14,
clear_width=83, rlflag=0) at screen.c:5605
5605 redraw_next = char_needs_redraw(off_from, off_to, endcol - col);
---------------------------------------------------------------------
Its 27 rows by 83 columns; nothing obvious yet.
I note that screen_line() computes off_to with
off_to = LineOffset[row] + coloff;
---------------------------------------------------------------------
(gdb) p row
$8 = 26
(gdb) p LineOffset[row]
$9 = 5439488
(gdb) p coloff
$10 = 0
---------------------------------------------------------------------
Looks like LineOffset[] has a problem. I don't see where LineOffset
is set up
---------------------------------------------------------------------
(gdb) p LineOffset
$11 = (unsigned int *) 0xf435e0
---------------------------------------------------------------------
Looks like a reasonable pointer.
---------------------------------------------------------------------
(gdb) p LineOffset[0]
$13 = 747
(gdb) p LineOffset[1]
$14 = 830
(gdb) p LineOffset[2]
$15 = 913
(gdb) p LineOffset[3]
$16 = 996
(gdb) p LineOffset[row-1]
$17 = 0
(gdb) p LineOffset[row-2]
I'm going to pass on figuring out what LineOffset is all about. I've
attached the file I've been using for testing.
Regards,
Chip Campbell
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
Runtime Environments
Mac OS X has two primary runtime environments: one based on the dynamic link
editor, dyld, and the other based on Code Fragment Manager (CFM). OS X does not
support ELF, and there's no dlopen, although the dlcompat library provides a
limited compatibility layer (using native OS X functions) so that common Unix
source can be compiled easily.
CFM determines addresses for referenced symbols in executables at build time (a
static approach). The executable format used is called PEF (Preferred
Executable Format). dyld resolves undefined symbols at execution time. The
executable format is Mach-O (Mach object-file-format).
Mac OS X is natively a dyld/Mach-O platform - all system frameworks are built
using dyld. In fact, the CFM/PEF environment is itself built on top of
dyld/Mach-O. However, there exist provisions to call dyld code from CFM code.
Moreover, if you wish to debug or trace a CFM application using GDB, you would
need to use a Mach-O program called LaunchCFMApp:
/System/Library/Frameworks/Carbon.framework/Versions/\ A/Support/LaunchCFMApp
dyld/Mach-O is similar in many respects to ld.so/ELF, although they differ both
conventionally and fundamentally. Some of these are:
* Dynamic shared libraries on Mac OS X have the .dylib extension. The
functionality of several traditional libraries (such as libc, libdl, libinfo,
libkvm, libm, libpthread, librpcsvc, etc.) is provided by a single dynamically
loadable framework, libSystem. libc.dylib etc. are simply symbolic links to
libSystem.dylib.
* Mac OS X builds libraries and applications with a two-level namespace (as
compared to a flat namespace in traditional Unix systems). This topic is
described in an Apple Developer Note called Two-Level Namespace Executables.
This also means that DYLD_INSERT_LIBRARIES, the dyld analog of ld.so's
LD_PRELOAD will not work with two-level namespace libraries. You can force a
flat namespace, but that often messes up things enough to stop the application
from running at all. Additionally, you cannot have "weak" symbols (symbols that
can be overridden) in libraries.
* Functionality similar to ldd (on Linux, say) is provided by
/usr/bin/otool.
Mac OS X uses Mach-O and not ELF simply because NEXTSTEP used Mach-O. Apple had
a large enough TODO list that moving to ELF for the sake of mainstream
conformity was not justified. Like NEXTSTEP, Mac OS X supports "fat" binaries
where an executable image contains binaries for more than one platform (such as
PowerPC and x86). Apple's port of GNU CC allow for fat binaries to be produced
(provided assemblers and libraries are available for each specified
architecture).
Prebinding
Mac OS X uses a concept called "prebinding" to optimize Mach-O applications to
launch faster. Prebinding is the reason you see the "Optimizing ..." message
when you update the system, or install certain software.
The dynamic link editor resolves undefined symbols in an executable (and
dynamic libraries) at run time. This activity involves mapping the dynamic code
to free address ranges and computing the resultant symbol addresses. If a
dynamic library is compiled with prebinding support, it can be predefined at a
given address range. This way, dyld can use predefined addresses to reference
symbols in such a library. Of course, for this to work, libraries cannot have
preferred addresses that overlap. Apple specifies address ranges for 3rd party
(including your own) libraries to use to support prebinding.
update_prebinding is run to (attempt to) synchronize prebinding information
when new files are added to a system. This can be a time consuming process even
if you add or change a single file, say, because all libraries and executables
that might dynamically load the new file must be found (package information is
used to help in this, and the process is further optimized by building a
dependency graph), and eventually redo_prebinding is run to prebind files
appropriately.
/usr/bin/otool can be used to determine if a binary is prebound:
# otool -hv /usr/lib/libc.dylib /usr/lib/libc.dylib: Mach header magic cputype
# cpusubtype filetype ncmds sizeofcmds flags MH_MAGIC PPC ALL DYLIB 10 1940 \
# NOUNDEFS DYLDLINK PREBOUND SPLIT_SEGS TWOLEVEL
