Hamish wrote:
might newer gcc's not like ""?
map = G_find_file2 ("cell", filename, "");
[src/libes/ogsf/Gs3.c Gs_build_256lookup()]
Nope; "" is a perfectly legal string literal (which contains only the
terminating NUL).
--
Glynn Clements <glynn.clements@virgin.net>
Hamish wrote:
maybe this can help shed some light:
http://mail.python.org/pipermail/python-dev/2002-December/031107.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=171353
"threading is an 8.4 feature. It's not even an option in 8.3."or perhaps this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=201062
I'll look at those later.
If it is limited to Debian/Testing for whatever reason, we can always
just make the adjustment in the Debian package & hopefully if it is a
glibc-land bug it will be sorted out before the next Debian release (a
new glibc & tcltk 8.4 should arrive into Testing in a couple of weeks,
e.g.). In the mean time I think most people running Debian Testing or
Unstable should be adventurous enough to add the change by hand if
compiling from source, thus a --nviz-pthread switch isn't needed (yet).I tried compiling with gcc 2.95, but that didn't make any difference. I
can't test with an older glibc without ripping everything up so I won't.
Looks like threading in Tcl8.4 though. I wonder if the tcl8.4 others
have reported working was built with the without-threading option?
Possibly. FWIW, does libtcl itself have a dependency upon libpthread
(according to ldd)? Or, for that matter, libGL?
One other thing which might be instructive would be to build your own
tclsh and/or wish executables (the source code for these programs is
normally installed as e.g. /usr/lib/tcl8.4/tclAppInit.c and
/usr/lib/tk8.4/tkAppInit.c), both with and without -lpthread, and see
how "exec" behaves. If libtcl doesn't have a dependency upon
libpthread, but a self-built tclsh/wish doesn't work without you
adding -lpthread to the link command, that suggests that libtcl needs
to have that dependency added.
I'm fairly sure that the problem isn't due to NVWISH2.2 calling fork()
itself; while it does import system(), that's only used for spawning
the NetPBM utilities when dumping PPM files.
--
Glynn Clements <glynn.clements@virgin.net>
Hamish wrote:
It apparently breaks while somewhere in this statement in
src/libes/gis/nme_in_mps.c:if(strchr(name, '@'))
sprintf (fullname, "%s", name);
else
sprintf (fullname, "%s@%s", name, mapset);--
Looking up strchr:char *strchr(const char *s, int c);
Description
This function returns a pointer to the first occurrence of c in s. Note
that if c is NULL, this will return a pointer to the end of the string.Return Value
A pointer to the character, or NULL if it wasn't found.So "if()" is testing either a pointer or NULL.
Is that kosher?
Yes. NULL is false, anything else is true.
If strchr() segfaults, it means that name is bogus (either the pointer
itself is invalid or the data to which it points doesn't have a
terminating NUL).
--
Glynn Clements <glynn.clements@virgin.net>
Glynn Clements wrote:
> http://mail.python.org/pipermail/python-dev/2002-December/031107.html
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=171353
> "threading is an 8.4 feature. It's not even an option in 8.3."
>
> or perhaps this:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=201062I'll look at those later.
FWIW, none of those are relevant.
--
Glynn Clements <glynn.clements@virgin.net>
> It apparently breaks while somewhere in this statement in
> src/libes/gis/nme_in_mps.c:
>
> if(strchr(name, '@'))
> sprintf (fullname, "%s", name);
> else
> sprintf (fullname, "%s@%s", name, mapset);If strchr() segfaults, it means that name is bogus (either the pointer
itself is invalid or the data to which it points doesn't have a
terminating NUL).
Upon closer look, it appears to get the segfault when I access 'mapset',
which explains why it would crash on the second+ pass through that
function.
I'll have to work backwards from there.
Hamish
Bug #1:
> maybe this can help shed some light:
> http://mail.python.org/pipermail/python-dev/2002-December/031107.html
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=171353
> "threading is an 8.4 feature. It's not even an option in 8.3."
FWIW, does libtcl itself have a dependency upon libpthread
(according to ldd)? Or, for that matter, libGL?
Yes & yes.
$ ldd /usr/lib/libtcl8.4.so
libdl.so.2 => /lib/libdl.so.2 (0x400b0000)
libpthread.so.0 => /lib/libpthread.so.0 (0x400b4000)
libm.so.6 => /lib/libm.so.6 (0x40103000)
libc.so.6 => /lib/libc.so.6 (0x40124000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
$ ldd /usr/lib/libGL.so
libpthread.so.0 => /lib/libpthread.so.0 (0x40078000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x400c8000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x400d5000)
libdl.so.2 => /lib/libdl.so.2 (0x40190000)
libc.so.6 => /lib/libc.so.6 (0x40193000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
One other thing which might be instructive would be to build your own
tclsh and/or wish executables (the source code for these programs is
normally installed as e.g. /usr/lib/tcl8.4/tclAppInit.c and
/usr/lib/tk8.4/tkAppInit.c), both with and without -lpthread, and see
how "exec" behaves. If libtcl doesn't have a dependency upon
libpthread, but a self-built tclsh/wish doesn't work without you
adding -lpthread to the link command, that suggests that libtcl needs
to have that dependency added.
That will have to wait until next week, but libtcl has it ..
regards,
Hamish
Hamish wrote:
> FWIW, does libtcl itself have a dependency upon libpthread
> (according to ldd)? Or, for that matter, libGL?Yes & yes.
> One other thing which might be instructive would be to build your own
> tclsh and/or wish executables (the source code for these programs is
> normally installed as e.g. /usr/lib/tcl8.4/tclAppInit.c and
> /usr/lib/tk8.4/tkAppInit.c), both with and without -lpthread, and see
> how "exec" behaves. If libtcl doesn't have a dependency upon
> libpthread, but a self-built tclsh/wish doesn't work without you
> adding -lpthread to the link command, that suggests that libtcl needs
> to have that dependency added.That will have to wait until next week, but libtcl has it ..
In which case, that test isn't likely to be useful.
OTOH, if you have the tkAppInit.c files for both 8.3 and 8.4, it might
be worth seeing if anything has changed (e.g. if you are supposed to
do some extra initialisation for 8.4).
--
Glynn Clements <glynn.clements@virgin.net>
Bug #2: (got it.)
> > It apparently breaks while somewhere in this statement in
> > src/libes/gis/nme_in_mps.c:
> >
> > if(strchr(name, '@'))
> > sprintf (fullname, "%s", name);
> > else
> > sprintf (fullname, "%s@%s", name, mapset);
>
> If strchr() segfaults, it means that name is bogus (either the
> pointer itself is invalid or the data to which it points doesn't
> have a terminating NUL).Upon closer look, it appears to get the segfault when I access
'mapset', which explains why it would crash on the second+ pass
through that function.I'll have to work backwards from there.
In src/libes/ogsf/GS2.c's GS_load_att_map(), the 'mapset' variable is
used uninitialized if "reuse" is true.
Moving the 'mapset=xxxx;' bit out of the condition to about line 1257
just before 'if (reuse)' stops the segfault; see the attached patch.
Could someone please test & commit to CVS if it's good, as I'll be out
of town until next week & won't be able to.
Looks ok, but I'm not really sure how much "reuse" reuses.. no chance of
using the wrong mapset from a previous call is there? That would be a
very ugly bug to catch.
forwards in all directions,
Hamish
GS2fix.diff (631 Bytes)
Moving the 'mapset=xxxx;' bit out of the condition to about line 1257
just before 'if (reuse)' stops the segfault; see the attached patch.
That patch is against 5.0.3rc3, by the way.
H
> Moving the 'mapset=xxxx;' bit out of the condition to about line 1257
> just before 'if (reuse)' stops the segfault; see the attached patch.That patch is against 5.0.3rc3, by the way.
(which needs it)
and it's already fixed in 5.3.
Hamish wrote:
> > Moving the 'mapset=xxxx;' bit out of the condition to about line 1257
> > just before 'if (reuse)' stops the segfault; see the attached patch.
>
>
> That patch is against 5.0.3rc3, by the way.
(which needs it)and it's already fixed in 5.3.
And in the CVS HEAD, AFAICT.
--
Glynn Clements <glynn.clements@virgin.net>
Concerning this patch: Should it be applied to 5.0.3 or not?
If yes, I'll prepare a 5.0.3RC4, otherwise we should release
5.0.3RC3.
Markus
On Wed, Sep 17, 2003 at 10:11:09PM +1200, Hamish wrote:
Bug #2: (got it.)
[...]
In src/libes/ogsf/GS2.c's GS_load_att_map(), the 'mapset' variable is
used uninitialized if "reuse" is true.Moving the 'mapset=xxxx;' bit out of the condition to about line 1257
just before 'if (reuse)' stops the segfault; see the attached patch.Could someone please test & commit to CVS if it's good, as I'll be out
of town until next week & won't be able to.Looks ok, but I'm not really sure how much "reuse" reuses.. no chance of
using the wrong mapset from a previous call is there? That would be a
very ugly bug to catch.forwards in all directions,
Hamish
--- src/libes/ogsf/GS2.c.ORIG 2002-08-13 09:45:19.000000000 +1200
+++ src/libes/ogsf/GS2.c 2003-09-17 21:55:09.000000000 +1200
@@ -1254,6 +1254,9 @@
begin = 0;
}+ /* Get MAPSET to ensure names are fully qualified */
+ mapset = G_find_cell2 (filename, "");
+
if (reuse)
{
gs->att[att].hdata = hdata;
@@ -1290,8 +1293,6 @@tbuff = gs_get_att_typbuff(gs, att, 1);
- /* Get MAPSET to ensure names are fully qualified */
- mapset = G_find_cell2 (filename, "");
filename = G_fully_qualified_name(filename, mapset);/* TODO: Provide mechanism for loading certain attributes at
--
Markus Neteler <neteler@itc.it> http://mpa.itc.it
ITC-irst, Istituto per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy
Markus Neteler wrote:
Concerning this patch: Should it be applied to 5.0.3 or not?
Yes. Otherwise the variable can be used without ever having been set,
which will result in a segfault.
--
Glynn Clements <glynn.clements@virgin.net>