Here we are. Any more must-fix things? How about word on the Win98 open dialog pango crash?
(someone gave me the missing bug numbers, but I absent-mindedly deleted the email... sorry about that :/)
2005-08-02 MenTaLguY <mental@...3...>
* src/selection-chemistry.cpp: backport crash fix from bulia [bug 1249899]2005-08-01 MenTaLguY <mental@...3...>
* src/gc-alloc.h: backport fix for improper allocation size2005-07-30 MenTaLguY <mental@...3...>
* src/sp-tspan.cpp: fix from bulia for incorrect tag name [bug 1247658] * packaging/win32/inkscape.nsi: fix from Adib to purge dlls from preexisting installation [bug 1247068]2005-07-29 MenTaLguY <mental@...3...>
* src/text-editing.cpp: another backport from cyreve [bug number??]2005-07-28 MenTaLguY <mental@...3...>
* Makefile.mingw.common, configure.ac, packaging/win32/inkscape.nsi, src/inkscape_version.h.mingw: bump version to 0.42+0.42.1cvs * src/dialogs/stroke-style.cpp: backport bulia's fix for stroke width spin button [bug number??] * src/text-editing.cpp: backport bulia's fix for text crash [bug 1247066] * src/libnrtype/Layout-TNG-OutIter.cpp: backport cyreve fix for crash on delete in virgin flowtext [bug 1245842] * configure.ac: Kees fix for libgc detection w/dlopen [bug number??]
On 8/3/05, MenTaLguY <mental@...3...> wrote:
Here we are. Any more must-fix things? How about word on the Win98 open dialog pango crash?
Ishmal made a debug build for me but I could not get any debugging from it :( It just never opens the console window before the crash. Ishmal, do you have any idea of what's going on?
* src/gc-alloc.h: backport fix for improper allocation size
Just curious - is this safe/important enough? Any memory leaks patched by this?
Quoting bulia byak <buliabyak@...400...>:
* src/gc-alloc.h: backport fix for improper allocationsize
Just curious - is this safe/important enough? Any memory leaks patched by this?
Memory leak? No, it was a potential crash bug. I'd misunderstood STL's memory allocation interface, so I was only allocating ( size ) bytes instead of the expected ( size * sizeof(T) ) bytes.
However, since GC::Alloc is not a normal part of GC allocation (just an adaptor for STL), only a small portion of the codebase was affected.
Breakdown:
Severity of Bug: CRITICAL [guaranteed buffer overruns] Likelihood of Occurence: LOW [rarely-used code] Risk of Fix: MINIMAL [simple, obviously correct fix]
-mental
Update on the open dialog crash: fixed by upgrading to newest libs (thanks Ishmal).
However I run into another problem: Cyrillic filenames crash on open in Win98. I traced this down to
fp = std::fopen(filename, how.c_str());
in io/sys.cpp, line 169. This fails, so fp == NULL.
However, Inkscape::IO::file_test on the same filename works, using g_file_test. So I thought that if I replace std::fopen with g_fopen in the above, it may work. Unfortunately this fails at linking:
libinkscape.a(sys.o):sys.cpp:(.text+0x2a7d): undefined reference to `g_fopen(char const*, char const*)'
Ishmal: is this function missing in your libs? Can you add it?
bulia byak wrote:
Update on the open dialog crash: fixed by upgrading to newest libs (thanks Ishmal).
However I run into another problem: Cyrillic filenames crash on open in Win98. I traced this down to
fp = std::fopen(filename, how.c_str());
in io/sys.cpp, line 169. This fails, so fp == NULL.
However, Inkscape::IO::file_test on the same filename works, using g_file_test. So I thought that if I replace std::fopen with g_fopen in the above, it may work. Unfortunately this fails at linking:
libinkscape.a(sys.o):sys.cpp:(.text+0x2a7d): undefined reference to `g_fopen(char const*, char const*)'
Ishmal: is this function missing in your libs? Can you add it?
Bulia:
'muntyan' on IRC helped me out on this. glib/gstdio.h has a bug, where someone forgot to put G_BEGIN_DECLS and G_END_DECLS (macros for extern "C") at the top and bottom of the file. It is already fixed in Glib's CVS, and I will update the bundle tomorrow. But you can hack the file yourself to get the link to work. It is just C++ mangling the name.
I hope that this works. It can relieve a lot of the filename hackery we have needed to do recently.
Bob
Bob Jamison wrote:
'muntyan' on IRC helped me out on this. glib/gstdio.h has a bug, where someone forgot to put G_BEGIN_DECLS and G_END_DECLS (macros for extern "C") at the top and bottom of the file. It is already fixed in Glib's CVS, and I will update the bundle tomorrow. But you can hack the file yourself to get the link to work. It is just C++ mangling the name.
I'm attaching the hacked file. It is identical to their current CVS.
/* gstdio.h - GFilename wrappers for C library functions * * Copyright 2004 Tor Lillqvist * * GLib is free software; you can redistribute it and/or modify it * under the terms of the GNU Lesser General Public License as * published by the Free Software Foundation; either version 2 of the * License, or (at your option) any later version. * * GLib is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with GLib; see the file COPYING.LIB. If not, * write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, * Boston, MA 02111-1307, USA. */
#ifndef __G_STDIO_H__ #define __G_STDIO_H__
#include <glib/gprintf.h>
#include <sys/stat.h>
G_BEGIN_DECLS
#if defined(G_OS_UNIX) && !defined(G_STDIO_NO_WRAP_ON_UNIX)
/* Just pass on to the system functions, so there's no potential for data * format mismatches, especially with large file interfaces. */
#define g_open open #define g_rename rename #define g_mkdir mkdir #define g_stat stat #define g_lstat lstat #define g_unlink unlink #define g_remove remove #define g_rmdir rmdir #define g_fopen fopen #define g_freopen freopen
#else /* ! G_OS_UNIX */
/* Wrappers for C library functions that take pathname arguments. On * Unix, the pathname is a file name as it literally is in the file * system. On well-maintained systems with consistent users who know * what they are doing and no exchange of files with others this would * be a well-defined encoding, preferrably UTF-8. On Windows, the * pathname is always in UTF-8, even if that is not the on-disk * encoding, and not the encoding accepted by the C library or Win32 * API. */
int g_open (const gchar *filename, int flags, int mode);
int g_rename (const gchar *oldfilename, const gchar *newfilename);
int g_mkdir (const gchar *filename, int mode);
int g_stat (const gchar *filename, struct stat *buf);
int g_lstat (const gchar *filename, struct stat *buf);
int g_unlink (const gchar *filename);
int g_remove (const gchar *filename);
int g_rmdir (const gchar *filename);
FILE *g_fopen (const gchar *filename, const gchar *mode);
FILE *g_freopen (const gchar *filename, const gchar *mode, FILE *stream);
#endif /* G_OS_UNIX */
G_END_DECLS
#endif /* __G_STDIO_H__ */
On 8/5/05, Bob Jamison <rwjj@...127...> wrote:
'muntyan' on IRC helped me out on this. glib/gstdio.h has a bug, where someone forgot to put G_BEGIN_DECLS and G_END_DECLS (macros for extern "C") at the top and bottom of the file. It is already fixed in Glib's CVS, and I will update the bundle tomorrow.
Thanks - that worked. What's better, replacing the std::fopen by g_fopen worked too. No more crashes!
So, Mental, here's one more patch for 42.1 attached (and committed to HEAD). I think it's pretty safe because it only affects WIN32, and moreover, only Windows 95/98. Jon Cruz: you may want to review this, as it's in your code.
Following which, I think I'm OK with releasing 0.42.1. Can others please give updates on the rest of the issues (OSX, FC crashes, anything else)? Should we do a prerelease?
bulia byak wrote:
Thanks - that worked. What's better, replacing the std::fopen by g_fopen worked too. No more crashes!
So, Mental, here's one more patch for 42.1 attached (and committed to HEAD). I think it's pretty safe because it only affects WIN32, and moreover, only Windows 95/98. Jon Cruz: you may want to review this, as it's in your code.
Following which, I think I'm OK with releasing 0.42.1. Can others please give updates on the rest of the issues (OSX, FC crashes, anything else)? Should we do a prerelease?
I uploaded a build with this fix, if people could please test it:
http://inkscape.org/win32/Inkscape0508050923.zip
I will upload the win32 libs again as soon as 7-zip is finished, which might be 3 cups of coffee from now.
Bob
Bob Jamison wrote:
I uploaded a build with this fix, if people could please test it:
http://inkscape.org/win32/Inkscape0508050923.zip
I will upload the win32 libs again as soon as 7-zip is finished, which might be 3 cups of coffee from now.
Ok, I am uploading it now:
http://inkscape.org/win32/gtk26-050805.7z
This is likely what we will use for 0.42.1
Bob
Bob Jamison wrote:
http://inkscape.org/win32/gtk26-050805.7z
This is likely what we will use for 0.42.1
I re-uploaded this with the Loudmouth static lib in it. Its time stamp is:
05-Aug-2005 12:55 25.3M
I also updated the Makedep files to include the whiteboard stuff, and updated Makefile.mingw to be able to use it.
However, for the next few days at least, I commented out the -DWITH_INKBOARD definition that is required to actually use it. Devs can uncomment this and do clean makes to experiment with it. But it should not be breaking the build during our release.
Bob
On Friday 05 August 2005 03:03 pm, Bob Jamison wrote:
However, for the next few days at least, I commented out the -DWITH_INKBOARD definition that is required to actually use it. Devs can uncomment this and do clean makes to experiment with it. But it should not be breaking the build during our release.
Out of curiosity, how is it breaking the build? I have tried building Inkscape CVS with and without --enable-inkboard, and the build process and resulting binary behave correctly in both situations.
-- David
David Yip wrote:
Out of curiosity, how is it breaking the build? I have tried building Inkscape CVS with and without --enable-inkboard, and the build process and resulting binary behave correctly in both situations.
Well, I guess you saw the compile problems. These are all minor, but I would still like to wait until after the release.
By the way, what is needed, I believe, is to call lm_initialize() once before any other calls to Loudmouth code. This is a no-op on Linux, but on Windows it calls WSAStartup(), which is necessary for any code that wants to use Winsock.
The error people are missing is 'getaddrinfo() failed' which is almost certainly because WSAStartup() had not been called first. The way to see these messages is to open the View/Messages dialog, select "Capture", and then try the offending operations.
Bob
On Saturday 06 August 2005 12:19 pm, Bob Jamison wrote:
David Yip wrote:
Out of curiosity, how is it breaking the build? I have tried building Inkscape CVS with and without --enable-inkboard, and the build process and resulting binary behave correctly in both situations.
Well, I guess you saw the compile problems. These are all minor, but I would still like to wait until after the release.
Hmm, alright -- I have no problems with that. Are you referring to the compiler warnings and such that occur?
By the way, what is needed, I believe, is to call lm_initialize() once before any other calls to Loudmouth code. This is a no-op on Linux, but on Windows it calls WSAStartup(), which is necessary for any code that wants to use Winsock.
Ah, okay -- I didn't see that in the Loudmouth documentation or API.
The proper place to insert lm_initialize() would probably be in src/jabber_whiteboard/connection-establishment.cpp in SessionManager::connectToServer, at approximately line 203 (before the call to lm_connection_new()). I've made the change here, but I don't want to commit the code I have just yet -- it's currently undergoing a rewrite, and is not yet reasonably stable.
-- David
David Yip wrote:
Ah, okay -- I didn't see that in the Loudmouth documentation or API.
The proper place to insert lm_initialize() would probably be in src/jabber_whiteboard/connection-establishment.cpp in SessionManager::connectToServer, at approximately line 203 (before the call to lm_connection_new()). I've made the change here, but I don't want to commit the code I have just yet -- it's currently undergoing a rewrite, and is not yet reasonably stable.
It might be in the patch. Anyway, I added it to SessionManager's constructor for now. I can take it out. But it does get past that first error. However, I don't know what proper operation is like, so I don't know where to go from here.
Bob
Bob Jamison wrote:
It might be in the patch. Anyway, I added it to SessionManager's constructor for now. I can take it out. But it does get past that first error. However, I don't know what proper operation is like, so I don't know where to go from here.
Hi, all,
Notes on Loudmouth0.90 on Win32 only:
I got a bit tired of hacking on Loudmouth code. That's their project, not ours! ^^
However, I did get three things done.
================================= 1. I made a static makefile so that anyone can hack on the patched Loudmouth source I posted, and try it out. It is attached. It is set up to use our /gtk26 dir.
================================= 2. In lm-sock.c, there is a bug. At line 46, the lines: u_long mode = (block ? 0 : 1); res = ioctlsocket(sock, FIONBIO, &mode);
should be : u_long mode = (block ? 1 : 0); res = ioctlsocket(sock, FIONBIO, &mode);
That's according to the ioctlsocket() manpage: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/win...
================================= 3. In lm-connection.c, the function connection_connect_cb() has the lines: } else if (condition == G_IO_OUT) { _lm_connection_succeeded (connect_data);
It should maybe be: } else if (condition == 0 || condition == G_IO_OUT) { _lm_connection_succeeded (connect_data);
So, if anyone wants to hack on this to make it work, please do so.
I'm Off To The Pub!
Bob (ishmal)
CC = mingw32-gcc CXX = mingw32-g++ AS = as AR = mingw32-ar RANLIB = ranlib WINDRES = windres DLLWRAP = dllwrap DLLTOOL = dlltool RM = del
OBJ = \ lm-connection.o \ lm-debug.o \ lm-error.o \ lm-message-handler.o \ lm-message-node.o \ lm-message.o \ lm-parser.o \ lm-proxy.o \ lm-sha.o \ lm-sock.o \ lm-ssl.o \ lm-utils.o
CFLAGS = -g -DLM_COMPILATION
####### Where is your GTK directory? GTK=c:/gtk26
####### Same thing, DOS style GTKDOS=c:\gtk26
INC = -I. -I.. -I$(GTK)/include/glib-2.0 -I$(GTK)/lib/glib-2.0/include
libloudmouth-1.a: $(OBJ) ar crv $@ $(OBJ) ranlib $@ copy /y libloudmouth-1.a $(GTKDOS)\lib
####### IMPLICIT RULES .cpp.o: $(CXX) $(CFLAGS) $(INC) -c -o $@ $<
.c.o: $(CC) $(CFLAGS) $(INC) -c -o $@ $<
clean: -$(RM) *.o -$(RM) *.a
I'm going to go ahead and add the loudmouth list into this thread. Hopefully we can get a 0.91 that builds cleanly.
--Ted
On Sat, 2005-08-06 at 15:21 -0500, Bob Jamison wrote:
Bob Jamison wrote:
It might be in the patch. Anyway, I added it to SessionManager's constructor for now. I can take it out. But it does get past that first error. However, I don't know what proper operation is like, so I don't know where to go from here.
Hi, all,
Notes on Loudmouth0.90 on Win32 only:
I got a bit tired of hacking on Loudmouth code. That's their project, not ours! ^^
However, I did get three things done.
=================================
- I made a static makefile so that anyone can hack on the patched
Loudmouth source I posted, and try it out. It is attached. It is set up to use our /gtk26 dir.
================================= 2. In lm-sock.c, there is a bug. At line 46, the lines: u_long mode = (block ? 0 : 1); res = ioctlsocket(sock, FIONBIO, &mode);
should be : u_long mode = (block ? 1 : 0); res = ioctlsocket(sock, FIONBIO, &mode);
That's according to the ioctlsocket() manpage: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/win...
================================= 3. In lm-connection.c, the function connection_connect_cb() has the lines: } else if (condition == G_IO_OUT) { _lm_connection_succeeded (connect_data);
It should maybe be: } else if (condition == 0 || condition == G_IO_OUT) { _lm_connection_succeeded (connect_data);
So, if anyone wants to hack on this to make it work, please do so.
I'm Off To The Pub!
Bob (ishmal)
plain text document attachment (Makefile.mingw)
CC = mingw32-gcc CXX = mingw32-g++ AS = as AR = mingw32-ar RANLIB = ranlib WINDRES = windres DLLWRAP = dllwrap DLLTOOL = dlltool RM = del
OBJ = \ lm-connection.o \ lm-debug.o \ lm-error.o \ lm-message-handler.o \ lm-message-node.o \ lm-message.o \ lm-parser.o \ lm-proxy.o \ lm-sha.o \ lm-sock.o \ lm-ssl.o \ lm-utils.o
CFLAGS = -g -DLM_COMPILATION
####### Where is your GTK directory? GTK=c:/gtk26
####### Same thing, DOS style GTKDOS=c:\gtk26
INC = -I. -I.. -I$(GTK)/include/glib-2.0 -I$(GTK)/lib/glib-2.0/include
libloudmouth-1.a: $(OBJ) ar crv $@ $(OBJ) ranlib $@ copy /y libloudmouth-1.a $(GTKDOS)\lib
####### IMPLICIT RULES .cpp.o: $(CXX) $(CFLAGS) $(INC) -c -o $@ $<
.c.o: $(CC) $(CFLAGS) $(INC) -c -o $@ $<
clean: -$(RM) *.o -$(RM) *.a
Bob Jamison wrote:
Bob Jamison wrote:
It might be in the patch. Anyway, I added it to SessionManager's constructor for now. I can take it out. But it does get past that first error. However, I don't know what proper operation is like, so I don't know where to go from here.
Hi, all,
Notes on Loudmouth0.90 on Win32 only:
I got a bit tired of hacking on Loudmouth code. That's their project, not ours! ^^
*snip*
Bob, I'm thankful for all that you've done so far because you've made the only progress we've had for win32+whiteboard. Unfortunately, it's still not functional on win32 though. I've made the modifications to the loudmouth files, compiled that, recompiled inkscape with the changes and there's no difference that I can tell. Through the connect to server dialog, when you click "connect" it does not appear to do anything, but, when you quit inkscape it remains in memory. I've triple checked now and anything normal done in inkscape, when you quit it end the process normally, but once you try to invoke the whiteboard stuff and then go to quit, it doesn't end the process. Unfortunately that's about all I know about what's right/wrong which is about as vague as you can get. I thought it may be helpful to know that info about it not exiting normally after trying to use the whiteboard stuff because maybe it's stuck in some kind of loop or just not "connecting" internally the way it should. Is it maybe due to it expecting the loudmouth stuff on win32 to be a dll still?
At this point I do have to say that David, if you could try and look into getting this operational on win32 it would be greatly helpful. Do you feel that this is a loudmouth issue at this point or potentially an inkscape issue? If loudmouth, we should see if we can get their devs into looking at this stuff. Otherwise, I know that you don't have a win32 box to develop on, but this is a feature that I've been thirsting for and am willing to be your win32 guinea pig if you have the time and suggestions. I have to say that using it on Linux was way cool, and it's a tease to have that menu taunting me on win32. ;)
-Josh
On Wednesday 10 August 2005 11:45 am, Joshua A. Andler wrote:
At this point I do have to say that David, if you could try and look into getting this operational on win32 it would be greatly helpful. Do you feel that this is a loudmouth issue at this point or potentially an inkscape issue?
It really seems to me that this is a Loudmouth issue. From what I can tell from the Loudmouth API and other documentation, the connection sequence used in the whiteboard code is correct.
I'm not yet sure why none of the menu items function, though.
I'm sending off an email to the Loudmouth development mailing lists about this...hopefully, they'll have some answers. The fact that there has been zero traffic on those lists since June worries me, but maybe people are still around. (Bob, it'd be great if you could do the same, since you've been hacking at Loudmouth on Win32.)
- David
On 8/3/05, MenTaLguY <mental@...3...> wrote:
Any more must-fix things?
Here's a new kind of crash with fedora rpms:
https://sourceforge.net/tracker/index.php?func=detail&aid=1250804&gr...
Who created these rpms? Any ideas?
participants (8)
-
unknown＠example.com -
Adib Taraben -
Bob Jamison -
bulia byak -
David Yip -
Joshua A. Andler -
MenTaLguY -
Ted Gould