Hi Bram,
> Michael Wookey wrote:
>
> > > One bug that I didn't fix. Build gvim.exe with OLE=no, run 'gvim -
> register',
> > > and watch it crash while trying to display an error message.
> >
> > This seems to fix the bug...
> >
> > Index: src/message.c
> > ===================================================================
> > --- src/message.c (revision 212)
> > +++ src/message.c (working copy)
> > @@ -2987,7 +2987,7 @@
> > * If 'verbosefile' is set write message in that file.
> > * Must come before the rest because of updating "msg_col".
> > */
> > - if (*p_vfile != NUL)
> > + if (p_vfile && *p_vfile != NUL)
> > verbose_write(s, maxlen);
> >
> > if (redir_fd != NULL
> > Index: src/misc2.c
> > ===================================================================
> > --- src/misc2.c (revision 212)
> > +++ src/misc2.c (working copy)
> > @@ -1748,7 +1748,7 @@
> > return NULL;
> > }
> > #endif
> > - while ((b = *p) != NUL)
> > + while (p && (b = *p) != NUL)
> > {
> > if (b == c)
> > return p;
> >
>
> Well, that may fix it, but the problem is that the order of
> initializations is violated. Normally all option pointers are not
> NULL.I think I've found it. In src/main.c:main(), the call to gui_prepare() needs to occur after set_init_1() for two reasons: 1. set_init_1() ends up initialising the options table - and therefore p_vfile. 2. The win32 implementation of gui_mch_prepare() as called from gui_prepare() calls ole_error() in an error path. ole_error() calls through to EMSG2() which eventually uses p_vfile. However since gui_prepare() is called before set_init_1(), p_vfile has not yet been initialised. The attached patch demonstrates the solution by moving gui_prepare() after set_init_1(). cheers
ole_register.patch
Description: ole_register.patch
