Re: [Denemo-devel] Release 1.0.8

[Richard Shann]

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