Follow-up Comment #7, bug #22351 (project gnustep):
This problem happens quite often in Debian as of Base 0.14 (which has the
--auto option by default), with many applications; users have reported such
problems on i386, powerpc and amd64. The solution in comment #1 does not
help, unfortunately.
Follow-up Comment #9, bug #22351 (project gnustep):
But this happens at a time when gdnc is either not started or is
non-functional, so it is safe to assume that no such connections exist. Isn't
it so? I may be totally wrong, I don't understand the code very well.
Here's how I've been able to
Follow-up Comment #14, bug #22351 (project gnustep):
No it's not safe to make any such assumption...
Ah, thanks. So my approach is entirely unacceptable, as you said.
Hopefully the changes to NSPortMessageNameServer.m to implement
locking...
I'll test extensively tomorrow at work, they
Follow-up Comment #19, bug #22351 (project gnustep):
I tested yesterday's changes to NSMessagePortNameServer.m (as applied on the
stable branch) with Debian's Base 1.14.1 and everything works as expected.
Many thanks for fixing this annoying problem.
URL:
http://savannah.gnu.org/bugs/?23792
Summary: PC cannot be built with LDFLAGS=-Wl,-z,defs
Project: GNUstep
Submitted by: yavor
Submitted on: Monday 07/07/2008 at 13:57
Category: Application
Severity:
URL:
http://savannah.gnu.org/bugs/?24083
Summary: Offset issues with the xmonad WM; blank windows
with the cairo backend
Project: GNUstep
Submitted by: yavor
Submitted on: Sat Aug 16 22:41:26 2008
Category: Backend
Follow-up Comment #2, bug #24083 (project gnustep):
I've never used xmonad, I just installed it to test this particular problem.
Here is what the OP replied:
I have no idea what business has GNUstep with window borders. The
application draws into its window and the window location on the
Follow-up Comment #4, bug #24083 (project gnustep):
I will need to know which version of cairo and
of GNUstep are being used.
Based on his Debian suite, they are:
cairo 1.6.4
Base 1.16.1
Gui/Back 0.14.0
___
Reply to this item at:
Follow-up Comment #8, bug #23876 (project gnustep):
AC_SYS_PROCFS is not a standard autoconf macro, just a macro polluting
autoconf's namespace (a common practice, unfortunately).
___
Reply to this item at:
Follow-up Comment #10, bug #23876 (project gnustep):
The macro definition is in config/procfs.m4. I don't know where it came
from, but definitely not Autoconf.
The test being performed there is going to fail in chroots that do not mount
/proc.
FWIW, it doesn't fail on Debian autobuilders;
Follow-up Comment #11, bug #23876 (project gnustep):
I just tried in a pbuilder chroot (which mounts /proc) -- the `mount' command
outputs nothing.
The attached trivial patch should be equally reliable and should DTRT in such
chroots. Funda Wang, does it work for you if you apply it and then
Follow-up Comment #3, bug #24109 (project gnustep):
It's not GNUstep Make's fault. It is the developer's responsibility to
ensure that LIBRARIES_DEPEND_UPON contains all the libraries the built library
has to link with; gnustep-make does not add anything by default (and that's
how it should be,
Follow-up Comment #6, bug #24109 (project gnustep):
I can't speak for this particular case, but...
As per Debian Policy it is a bug if a program or a library has unresolved
symbols; this is to ensure that the shlibs system works properly and all
dependencies for the package are computed
Follow-up Comment #9, bug #24083 (project gnustep):
Many thanks...
The OP confirmed that the NSBezierPath.m patch resolves the problem with
cairo, so this bug remains for the (minor) xmonad issue.
___
Reply to this item at:
URL:
http://savannah.gnu.org/bugs/?24526
Summary: Crash on x86_64 when a program is started with
argument that is invalid property list
Project: GNUstep
Submitted by: yavor
Submitted on: Sat Oct 11 00:07:44 2008
Follow-up Comment #2, bug #24526 (project gnustep):
It was reproduced by the original bug reporter with gnustep-startup-0.20, but
I also asked him to try with Base SVN trunk -- same result.
I assume that you cannot reproduce on x86_64, right?
Follow-up Comment #4, bug #24526 (project gnustep):
Thanks. If the `signal' implementation on that system is broken, I suspect
there would be other severe problems in Emacs that would occur before
byte-compiling the Emacs Lisp files. We'll investigate.
Follow-up Comment #5, bug #24526 (project gnustep):
A friend who is an official Debian Developer managed to reproduce this on
Debian GNU/Linux amd64 (sid), using the debian gnustep-base package (version
1.16.3), installed specifically for this test.
Attached are two files with backtraces -- one
Follow-up Comment #7, bug #24526 (project gnustep):
but then a gdb backtrace of something different, not of the core image
dumped.
Correct, but in fact it is a crash while executing this preciese command from
the make recipe. I can ask him to run gdb on the core, if it helps. It has
Follow-up Comment #8, bug #24526 (project gnustep):
One more thing. Another person could not reproduce this on Debian Etch,
amd64, Base version 1.13.0. The test program exited with code 1 and zero when
NOHANDLE is defined, as expected.
This (old) version of GNUstep Base does not have the
Follow-up Comment #1, bug #24785 (project gnustep):
I can confirm this behavior with Preferences on GNU/kFreeBSD, GUI version
0.14.0.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?24785
Follow-up Comment #10, bug #24526 (project gnustep):
Sorry for replying so late.
I can't reproduce with Base 1.18.0 on x86_64-linux-gnu; I even managed to
bootstrap Emacs without other errors, which was quite surprising. Please
close the bug, thanks.
Follow-up Comment #17, bug #24083 (project gnustep):
Fred -- sorry for the delay. The OP reports this is fixed in 0.16.0, so
please close. Thanks!
___
Reply to this item at:
http://savannah.gnu.org/bugs/?24083
URL:
http://savannah.gnu.org/bugs/?26895
Summary: NSFontDescriptor.h not included from AppKit.h
Project: GNUstep
Submitted by: yavor
Submitted on: Fri Jun 26 12:52:23 2009
Category: Gui/AppKit
Severity: 3
URL:
http://savannah.gnu.org/bugs/?27222
Summary: By default binaries should be built with '-g -O2'
Project: GNUstep
Submitted by: yavor
Submitted on: Tue 11 Aug 2009 12:02:16 AM EEST
Category: Makefiles
Follow-up Comment #2, bug #27222 (project gnustep):
I think there are still plenty of bugs on some targets with -O3 and higher,
so this seems risky.
I think this is most natural:
* debug=yes (default): -g -O2
* debug=no: -O2
If a developer/user wants unoptimized build for better debugging,
URL:
http://savannah.gnu.org/bugs/?29208
Summary: NSCalendarDate's format does not support the %k
conversion specifier
Project: GNUstep
Submitted by: yavor
Submitted on: Fri 12 Mar 2010 03:41:18 PM EET
Category:
Follow-up Comment #2, bug #29208 (project gnustep):
Thanks. Here is my attemt; I'd appreciate a thorough review. The leading
space is important for sorting/alignment -- I see that %e omits it (contrary
to what the documentation says); probably to match Cocoa behavior?
Tested with the attached
URL:
http://savannah.gnu.org/bugs/?29845
Summary: FTBFS on GNU/Hurd with -Wl,--no-undefined
Project: GNUstep
Submitted by: yavor
Submitted on: Mon May 10 11:27:13 2010
Category: Base/Foundation
Severity:
Follow-up Comment #3, bug #29845 (project gnustep):
No news, unfortunately. I'd be glad to provide a patch if I only knew what
would be the correct fix... It seems that all platforms which use the
GS_FAKE_MAIN hack are affected; on GNU/Linux you can reproduce the problem
with
./configure
Follow-up Comment #5, bug #29845 (project gnustep):
Ah ... so '-Wl,-z,defs -Wl,--as-needed' has a similar effect to
'-Wl,--no-undefined'
Almost; -Wl,-z,defs is another way of writing -Wl,--no-undefined.
the fake main mechanism requires the gnustep_base_user_main() function to
be
undefined
URL:
http://savannah.gnu.org/bugs/?30094
Summary: (Regression) FTBFS on GNU/kFreeBSD: sync.m:87:
error: 'PTHREAD_MUTEX_RECURSIVE' undeclared
Project: GNUstep
Submitted by: yavor
Submitted on: Wed Jun 9 14:38:36 2010
Follow-up Comment #8, bug #29845 (project gnustep):
Seems to be working fine. Thank you very much.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?29845
___
Message sent via/by
Follow-up Comment #5, bug #30094 (project gnustep):
Strange, but if that works, OK.
There are 3 more places where this condition needs to be changed, could you
please do that?
GSPThread.h, NSLock.m, NSZone.m
___
Reply to this item at:
Follow-up Comment #9, bug #30094 (project gnustep):
Unfortunately I won't be able to confirm that the failure is fixed on
GNU/kFreeBSD until gnustep-base 1.20.x is uploaded to Debian (either with the
upstream fix, or the same as a Debian patch). It's like a chicken and egg
problem for us...
So
Follow-up Comment #4, bug #28014 (project gnustep):
config.log should contain details about why this AC_CHECK_LIB test was
unsuccessful. Could you please look and post the relevant output?
___
Reply to this item at:
Follow-up Comment #2, bug #30285 (project gnustep):
The Autoconf manual (node `Header Portability') says:
`inttypes.h' vs. `stdint.h'
The C99 standard says that `inttypes.h' includes `stdint.h', so
there's no need to include `stdint.h' separately in a standard
environment. Some
URL:
http://savannah.gnu.org/bugs/?30299
Summary: Renaissance needs to link against needed libraries
Project: GNUstep
Submitted by: yavor
Submitted on: Wed 30 Jun 2010 10:13:52 AM EEST
Category: Libraries
URL:
http://savannah.gnu.org/bugs/?30766
Summary: Serious problems on hppa -- all programs abort with
malloc assertion failure
Project: GNUstep
Submitted by: yavor
Submitted on: Fri 13 Aug 2010 12:41:01 PM EEST
Category:
Follow-up Comment #2, bug #30766 (project gnustep):
This happens with all programs (gdnc, pl2link, etc...) It was discovered
while building gnustep-gui which invokes the just built make_services during
the build process.
Could you please run this program under valgrind?
Valgrind is not
Follow-up Comment #4, bug #30766 (project gnustep):
The later two could be ruled out by running a non GNUstep
Objective-C program compile don this machine.
Base 1.19.3 runs fine, so I guess they can be ruled out right away.
Next you should check which of the different cases for argument
Follow-up Comment #5, bug #30766 (project gnustep):
Here is some information about this architecture, in case it can be of help.
Type size:
short 2
int 4
long 4
long long 8
float 4
double8
long double 8
data pointer 4
endianness: big
unaligned
Follow-up Comment #8, bug #30766 (project gnustep):
Base 1.19.3 runs fine, so I guess they can be ruled out right
away.
Unfortunately not as it's perfectly possible for some code to
trigger bugs in the compiler or runtime that other code does
not trigger.
Right, I was thinking along the
Follow-up Comment #9, bug #30766 (project gnustep):
FYI: I asked the original bug reporter to try 1.20.0; it still fails in the
same way.
I'll wait for my tests with a debianized gcc before doing anything else.
___
Reply to this item at:
Follow-up Comment #11, bug #30766 (project gnustep):
Here is another backtrace from a different program (test3.m) that doesn't use
NSProcessInfo:
Program received signal SIGABRT, Aborted.
0x40fc98ac in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:67
67
Follow-up Comment #13, bug #30766 (project gnustep):
I asked the bug reporter to commence the bisection procedure, starting from
the tip (just in case), then narrowing between the last good r28586 (1.19.3)
and bad r30325 (1.20.0).
I'll followup here with the results as soon as I have them.
Follow-up Comment #15, bug #30766 (project gnustep):
Further narrowed down to -r28600:r28625 (continuing).
I asked on debian-hppa about some information for the switch from
Linuxthreads to NPTL on hppa -- I remember it was very hard, and there were
some odd details. It may turn out to be a
Follow-up Comment #16, bug #30766 (project gnustep):
Final results:
- r28611 is ok
- r28612 didn't compile [1]
- r28613 exposes the bug
[1]
NSLock.m: In function ‘-[NSCondition lockBeforeDate:]’:
NSLock.m:247: warning: passing argument 1 of ‘pthread_mutex_trylock’
from
incompatible pointer
Follow-up Comment #17, bug #30766 (project gnustep):
Looking at the diff, the only thing that comes to (my) mind is some oddity
with hiding the pthread stuff (hppa has the largest size of pthread_mutex_t --
48 -- but this shouldn't be a problem AFAICS), or the NSRunLoop change.
Should I ask to
Follow-up Comment #18, bug #30766 (project gnustep):
FWIW, link to the discussion that lead to this particular change:
http://thread.gmane.org/gmane.comp.lib.gnustep.general/33167
___
Reply to this item at:
Follow-up Comment #19, bug #30766 (project gnustep):
I asked Carlos O'Donnel, the author of the glibc NPTL code for hppa if
there's something wrong in the approach of hiding pthread internals with
opaque types of the same size. He said:
Yes, you don't take into account the alignment
Follow-up Comment #21, bug #30766 (project gnustep):
Yes, I'm glad to confirm this fixes the problem. It was not tested on the
official autobilders yet, but I doubt there will be any problems (and if there
are, they would be entirely my fault when incorporating the patch).
Thanks very much!
Follow-up Comment #23, bug #30766 (project gnustep):
How does it fail exactly? Can you post the relevant portions from
config.log?
___
Reply to this item at:
http://savannah.gnu.org/bugs/?30766
Follow-up Comment #25, bug #30766 (project gnustep):
Looks like pthread.h is not included in the test program. See if the
attached patch helps.
(file #21281)
___
Additional Item Attachment:
File name: AC_CHECK_ALIGNOF.patch
URL:
http://savannah.gnu.org/bugs/?42410
Summary: gdomap does not support IPv6
Project: GNUstep
Submitted by: yavor
Submitted on: Fri 23 May 2014 07:43:54 PM EEST
Category: Base/Foundation
Severity: 3 -
URL:
http://savannah.gnu.org/bugs/?42411
Summary: gdomap chroots to /tmp
Project: GNUstep
Submitted by: yavor
Submitted on: Fri 23 May 2014 07:54:06 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
URL:
http://savannah.gnu.org/bugs/?42423
Summary: base.make errouneously pollutes CONFIG_SYSTEM_*
variables
Project: GNUstep
Submitted by: yavor
Submitted on: Mon 26 May 2014 01:38:46 AM EEST
Category: Base/Foundation
URL:
http://savannah.gnu.org/bugs/?42433
Summary: [cairo] FTBFS with -Wl,--no-undefined
Project: GNUstep
Submitted by: yavor
Submitted on: Tue 27 May 2014 01:29:47 AM EEST
Category: Backend
Severity: 3 -
URL:
http://savannah.gnu.org/bugs/?42606
Summary: libopal: unfortunate library name
Project: GNUstep
Submitted by: yavor
Submitted on: Tue 24 Jun 2014 05:28:14 PM EEST
Category: Libraries
Severity: 3 -
URL:
http://savannah.gnu.org/bugs/?42640
Summary: GNUstep Make does not honor CFLAGS
Project: GNUstep
Submitted by: yavor
Submitted on: Sun 29 Jun 2014 02:05:00 PM EEST
Category: Makefiles
Severity: 3 -
URL:
http://savannah.gnu.org/bugs/?42641
Summary: Use makeinfo --html to generate HTML manuals from
.texi documents
Project: GNUstep
Submitted by: yavor
Submitted on: Sun 29 Jun 2014 07:08:06 PM EEST
Category: Makefiles
URL:
http://savannah.gnu.org/bugs/?42642
Summary: Use -include directive for deb.make
Project: GNUstep
Submitted by: yavor
Submitted on: Sun 29 Jun 2014 07:27:24 PM EEST
Category: Base/Foundation
Severity:
URL:
http://savannah.gnu.org/bugs/?42645
Summary: Use libgcrypt only if needed
Project: GNUstep
Submitted by: yavor
Submitted on: Sun 29 Jun 2014 09:36:19 PM EEST
Category: Base/Foundation
Severity: 3 -
Follow-up Comment #8, bug #24109 (project gnustep):
Nicola wrote:
libgnustep-gui is not linked against libobjc.
That is done on purpose (eg see #9920).
It is not clear from that bug *why* it is done on purpose...
So ... what advantages would this change bring ?
It's the other way around
URL:
http://savannah.gnu.org/bugs/?42648
Summary: Manual page for gnustep-tests
Project: GNUstep
Submitted by: yavor
Submitted on: Sun 29 Jun 2014 11:10:58 PM EEST
Category: Makefiles
Severity: 3 - Normal
URL:
http://savannah.gnu.org/bugs/?42649
Summary: Bootstrapping issue with the documentation
Project: GNUstep
Submitted by: yavor
Submitted on: Mon 30 Jun 2014 01:17:49 AM EEST
Category: Base/Foundation
URL:
http://savannah.gnu.org/bugs/?42650
Summary: Tools are linked with unnecessary libraries
Project: GNUstep
Submitted by: yavor
Submitted on: Mon 30 Jun 2014 01:53:23 AM EEST
Category: Base/Foundation
Follow-up Comment #3, bug #29730 (project gnustep):
Here is a proposed patch to fix this issue. While here, I also fixed
clean/distclean so that all generated files are deleted. The comments are
probably more verbose than needed, feel free to trim them.
P.S.
URL:
http://savannah.gnu.org/bugs/?42693
Summary: Fix build on mips64(el) with GCC
Project: GNUstep
Submitted by: yavor
Submitted on: Mon 07 Jul 2014 05:48:44 AM EEST
Category: Base/Foundation
Severity: 3
Follow-up Comment #4, bug #42698 (project gnustep):
I am not sure it was in the same discussion. Anyway. The dependency on
Renaissance is not a problem at all.
I even made the case that libEOModeler could be
shipped with DBModeler here
It is exactly what we are doing.
Perhaps we should
Follow-up Comment #2, bug #42698 (project gnustep):
We can try to ship both apps with a bit of effort. EOModeler is distributed
as a private library in Debian, because David Ayers once told us it was going
to undergo major changes. Is the current split what he meant back then? What
are the
Follow-up Comment #5, bug #42698 (project gnustep):
(MySQL+Postgres in one package)
Of course I meant SQLite, not MySQL.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?42698
___
URL:
http://savannah.gnu.org/bugs/?42717
Summary: Crash in -[NSBox(Private)
calcSizesAllowingNegative:]
Project: GNUstep
Submitted by: yavor
Submitted on: Wed 09 Jul 2014 04:48:17 PM EEST
Category: Gui/AppKit
Follow-up Comment #2, bug #42717 (project gnustep):
Yep, I noticed that dubious aFlag too. It looks like it is exactly the same
problem that was reported in 2013.
If I put a break on -[NSBox setBorderType:], aType is garbage (10-digit
number) instead of the expected value of 3. Going further
Follow-up Comment #3, bug #42717 (project gnustep):
When built with -O1, -calcSizesAllowingNegative: doesn't crash when called
from -setBorderType: (aType there is 3 as expected) but from
-setTitlePosition:
Breakpoint 1, -[NSBox setTitlePosition:] (self=0x921f6b0,
_cmd=0xb7edb618
URL:
http://savannah.gnu.org/bugs/?42729
Summary: [DBusKit] Unnecessary libtool usage
Project: GNUstep
Submitted by: yavor
Submitted on: Fri 11 Jul 2014 04:26:11 PM EEST
Category: Libraries
Severity: 3 -
URL:
http://savannah.gnu.org/bugs/?42730
Summary: [DBusKit] Misc texinfo formatting fixes
Project: GNUstep
Submitted by: yavor
Submitted on: Fri 11 Jul 2014 06:06:44 PM EEST
Category: Libraries
Severity: 3
URL:
http://savannah.gnu.org/bugs/?42732
Summary: [Performance] Uses Base but doesn't link with it
Project: GNUstep
Submitted by: yavor
Submitted on: Fri 11 Jul 2014 07:55:19 PM EEST
Category: Libraries
URL:
http://savannah.gnu.org/bugs/?42733
Summary: [SQLClient] Uses Base but doesn't link with it
Project: GNUstep
Submitted by: yavor
Submitted on: Fri 11 Jul 2014 08:21:59 PM EEST
Category: Libraries
URL:
http://savannah.gnu.org/bugs/?42734
Summary: [SQLClient] Unused config.{sub,guess}
Project: GNUstep
Submitted by: yavor
Submitted on: Fri 11 Jul 2014 09:01:32 PM EEST
Category: Libraries
Severity: 3 -
URL:
http://savannah.gnu.org/bugs/?42740
Summary: Some tests inevitably fail in a chroot
Project: GNUstep
Submitted by: yavor
Submitted on: Sat 12 Jul 2014 02:09:54 PM EEST
Category: Base/Foundation
Follow-up Comment #2, bug #42411 (project gnustep):
I don't know either, I'll ask the original bug submitter.
is there a debian specific standard for this which
could be conditionally compliled when building on a
debian system?
I don't think so. I believe this was not caught by an automatic
Follow-up Comment #2, bug #42423 (project gnustep):
That change was to avoid conflicting library versions
being linked into base and gui ...
I see. The way to address this problem is to take care to relink all reverse
dependencies of the library. Which I agreee is a bit tedious and even
URL:
http://savannah.gnu.org/bugs/?42762
Summary: Large file support
Project: GNUstep
Submitted by: yavor
Submitted on: Sun 13 Jul 2014 05:05:46 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
Follow-up Comment #4, bug #42717 (project gnustep):
As I ran out of ideas I made a binary search. The bad commit is r34050.
It's not easy for me to spot what's wrong, though...
___
Reply to this item at:
Follow-up Comment #5, bug #42717 (project gnustep):
Moving the NSTitleCell decoding at the beginning as in the attached patch
makes Cenon load with 0.24.0. -calcSizesAllowingNegative: accesses _cell so
at first glance it looks like the correct change. However, if I apply the
patch against trunk
Follow-up Comment #7, bug #42717 (project gnustep):
I was sure I mentioned it was the Main.xib file, but apparently missed that.
Sorry. I tried --GNU-Debug=XIB as soon as I found out the crash happens when
loading the XIB file, but was completely lost in the data it spits. Attached
is the
URL:
http://savannah.gnu.org/bugs/?42778
Summary: Frameworks with different SONAME cannot coexist
Project: GNUstep
Submitted by: yavor
Submitted on: Tue 15 Jul 2014 08:28:37 PM EEST
Category: Makefiles
URL:
http://savannah.gnu.org/bugs/?42782
Summary: Crash when loading a gorm file
Project: GNUstep
Submitted by: yavor
Submitted on: Wed 16 Jul 2014 03:22:11 PM EEST
Category: Gui/AppKit
Severity: 3 -
Follow-up Comment #2, bug #42782 (project gnustep):
GNUstep Base is built with detached debugging symbols and the -dbg package is
installed. The stack gets seriously messed up or destroyed.
___
Reply to this item at:
URL:
http://savannah.gnu.org/bugs/?42789
Summary: [SQLClient] Two versions of the library cannot
coexist peacefully
Project: GNUstep
Submitted by: yavor
Submitted on: Thu 17 Jul 2014 11:32:46 AM EEST
Category: Libraries
Follow-up Comment #1, bug #42804 (project gnustep):
Just another confirmation:
$ locale
LANG=en_US.ISO-8859-1
LANGUAGE=
LC_CTYPE=en_US.ISO-8859-1
LC_NUMERIC=en_US.ISO-8859-1
LC_TIME=en_US.ISO-8859-1
LC_COLLATE=en_US.ISO-8859-1
LC_MONETARY=en_US.ISO-8859-1
LC_MESSAGES=en_US.ISO-8859-1
Follow-up Comment #9, bug #42717 (project gnustep):
Here's the valgrind output:
$ valgrind Cenon
==14425== Memcheck, a memory error detector
==14425== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==14425== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
Follow-up Comment #4, bug #42782 (project gnustep):
==15741== Command: Gorm
/tmp/viewpdf.app-0.2dfsg1/English.lproj/Document.gorm/
==15741==
2014-07-20 19:27:38.764 Gorm[15741] Tiff Error (GSTiffReadData) Not a TIFF or
MDI file, bad magic number 20039 (0x4e47)
2014-07-20 19:27:42.187
Follow-up Comment #6, bug #42782 (project gnustep):
Gorm doesn't crash now but it doesn't load the file either. An alert panel is
shown with title Alert and No information as message. The image file
is, oddly enough, data.info. Here's the backtrace when this method is
reached:
Breakpoint 1,
Follow-up Comment #11, bug #42717 (project gnustep):
No crash if I apply your changes in r38003.
If it is a compiler bug, most probably it is present in earlier versions as
this bug was reported last year when 4.9 was not released yet. However, it
may be that GCC is taking advantage of the
Follow-up Comment #1, bug #42778 (project gnustep):
Actually, it is even more serious than that. Installing a new version of the
framework will wipe out the old one completely, so there will only be one
Version, with Current pointing to it. This is done unconditionally as the
first command of
Follow-up Comment #8, bug #42782 (project gnustep):
Yes, the info type is there and the array is quite large:
(gdb) po [NSImage imageFileTypes]
(tiff, tif, pnm, ppm, gif, jpeg, jpg, png, icns, 3fr, a, aai, ai, art, arw,
avi, avs, b, bgr, bgra, bie, bmp, bmp2, bmp3, brf, c, cal, cals, canvas,
Follow-up Comment #9, bug #42782 (project gnustep):
FYI, the bug is reproducible if I rebuild GUI with --disable-imagemagick (the
image file types are just tiff, tif, pnm, ppm, gif, jpeg, jpg, png, icns in
that case). The gdb backtrace is meaningless again and the valgrind output
is:
==8543==
Follow-up Comment #11, bug #42782 (project gnustep):
Yes, I used Gorm 1.2.20 + your latest changes. Most probably it is not an
issue with Gorm at all.
I'd really wish to provide more information... Perhaps I could put
breakpoints at some places and step through from there, this would at least
1 - 100 of 194 matches
Mail list logo
