Re: [Denemo-devel] Release 1.0.8

[Richard Shann]

Jeremiah, 

I have checked into master some code that might help fix/diagnose the
failure of the windows executable to run. Could you create a windows
binary from master for me to test. And, if possible, could you check in
to your github gub repository the stuff needed to make this build so I
can try and do it myself?

Thanks

Richard


On Sat, 2013-09-28 at 09:30 +0100, Richard Shann wrote:
> I ran the windows binary under gdb and it segfaults with a memory double
> free error in add_font_file() which comes immediately after the first
> find() call. The find() function is as follows
> 
> gchar*
> find_dir_for_file(gchar* filename, gchar* dirs[])
> {
>   gchar *dir = NULL;
>   gchar *path = NULL;
>   gint i;
> 
>   for(i = 0; dirs[i]; i++)
>   {
>     if(!dir)
>     {
>       path = g_build_filename (dirs[i], filename, NULL);
>       if(g_file_test (path, G_FILE_TEST_EXISTS))
>         dir = g_strdup(dirs[i]);
>       g_free(path);
>     }
>     g_free(dirs[i]);
>   }
>   return dir;
> }
> 
> I can't spot the memory allocation error in here (and it is unusual that
> denemo is only segfaulting under the debugger, not when executed without
> gdb), but I fear one of those hard to track down memory free errors is
> to blame.
> 
> However, this is consistent with the pattern that the find() function is
> failing to give windows paths that it can open. I set the soundfont path
> in the preferences and on re-running denemo windows opened the sound
> font ok, while it fails to open it with the result of the find() call
> (presumably NULL, the value is not checked in init_environment() where
> it is called).
> 
> Richard
> 
> 
> On Fri, 2013-09-27 at 19:41 +0100, Richard Shann wrote:
> > On Fri, 2013-09-13 at 16:31 +0100, Richard Shann wrote:
> > > On Fri, 2013-09-13 at 07:57 -0500, Jeremiah Benham wrote:
> > > > I created/uploaded a windows binary. Please test.
> > > Hmm, I ran this on the vista box which I have tested the most on. It
> > > fails to find things - stating with fluidsynth sound font (I think) and
> > > ending with failing to find denemoui.xml
> > > I tried starting it up in /usr/share/denemo/ui where that file is
> > 
> > I made some progress with this: by putting the ui directory inside the
> > C:\Program Files\Denemo\usr\bin directory I got Denemo to find
> > denemoui.xml on startup. This works because Eloi made Denemo check for
> > ui/denemoui.xml in the current working directory on startup. So this
> > check worked, and the file was found and opened. But when that is not
> > present it should check 
> > C:\Program Files\Denemo\usr\share\denemo\ui\denemoui.xml
> > 
> > but apparently that fails, though the file is present.
> > 
> > Having got passed the fatal error of not finding denemoui.xml it starts
> > up and even runs LilyPond on the initial empty score ok. But in fact
> > during startup it has failed to find the scheme scripts, so there is a
> > lot not working. Using the Scheme window I could run the scheme
> > procedure
> > 
> > (getenv "GUILE_LOAD_PATH")
> > 
> > and hence verify that the correct guile load path was in the environment
> > (as claimed during start up). So this is a puzzle. I have looked back to
> > see what changes might have affected finding files and found this
> > suspicious code which I think is due to Eloi:
> > 
> > 
> > const gchar*
> > get_executable_dir ()
> > {
> >   static const gchar* dir = NULL;
> >   if(dir == NULL)
> >   {
> >     char path[1024];
> > 
> > #ifdef G_OS_WIN32
> >     GetModuleFileNameW(NULL, path, MAX_PATH);
> > 
> > #elif defined _MACH_O_
> >     char path[1024];
> >     guint size = sizeof (path);
> >     _NSGetExecutablePath (path, &size);
> > 
> > #else
> >    readlink("/proc/self/exe", path, sizeof(path));
> > 
> > #endif
> >     dir = g_path_get_dirname(path);
> >   }
> >   return dir;
> > }
> > 
> > I *think* I see several problems here: the char path[1024] is declared
> > twice in the _MACH_O_ case, and the MAX_PATH seems un-related to the
> > 1024 value, and reading the Microsoft docs for GetModuleFileNameW it
> > seems that this string is not NULL terminated under Windows XP if it
> > exceeds MAX_PATH TCHARS (whatever they are
> > http://msdn.microsoft.com/en-us/library/windows/desktop/ms683197%
> > 28v=vs.85%29.aspx
> > 
> > But none of this would seem an obvious cause of failing to find most of
> > the files (soundfont, scheme scripts ...), denemoui.xml on windows.
> > Another thing that worries me is the use of ".." as a path element - I
> > *think* this does work on windows, but I am not certain. But again, this
> > doesn't seem to be a killer (why is get_executable_dir() needed - I
> > thought we were using a portable function from Glib for that?)
> > 
> > None would explain why guile fails to find things in the GUILE_LOAD_PATH
> > - that code is AFAIK untouched.
> > 
> > As it is, we don't have much of a release to offer :(
> > 
> > Richard
> > 
> > 
> > 
> > 
> >  
> > 
> > 
> > _______________________________________________
> > Denemo-devel mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/denemo-devel
> 
> 
> 
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/denemo-devel