[bug #24054] Segmentation fault in GSTest

[Fred Kiefer]

Follow-up Comment #9, bug #24054 (project gnustep):

I changed my printf statement and moved it to different places. This is what
I get now:

end thread pool cache 0x823ad04 current thread 0x823ace0 ended thread
0xb40004c0 count 1
push pool 0x823b330 thread 0x823ace0 count 2
pop pool 0x823b330 thread 0x823ace0 count 2
push pool 0x8222ee8 thread 0x823ace0 count 2
pop pool 0x8222ee8 thread 0x823ace0 count 2
push pool 0x8342e90 thread 0x823ace0 count 2
pop pool 0x8342e90 thread 0x823ace0 count 2
free pool cache 0x823ad04 thread 0x823ace0 count 1
pop pool 0x82425b8 thread 0x823ace0 count 1
finished free pool cache 0x823ad04 thread 0x823ace0 count 0
empty pool 0x823b330 thread 0x823ace0

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb5920b90 (LWP 9299)]
0xb78b9734 in objc_msg_lookup () from /usr/lib/libobjc.so.2

Some thread finishes and from the endThread: method we try to clean up the
corresponding pool cache. But it looks like we clean up the pool cache of the
current thread and of course things go horribly wrong after that. At least
this is how I interpret the printed results at the moment. I will try to
change the code and see if it improves things.


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #24054] Segmentation fault in GSTest

[Fred Kiefer]

Update of bug #24054 (project gnustep):

  Status:None => Fixed  
 Assigned to:None => FredKiefer 
 Open/Closed:Open => In Test

___

Follow-up Comment #10:

Looks like this was the cause of the problem. The code was cleaning up the
autorelease pool cache of the current thread and not of the thread that was
being released.

The only remaining problem with the NSAnimation test is that it is leaking
GSArray objects.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #23740] Getting "invalid type xxxx" when drawing

[Gregory John Casamento]

Follow-up Comment #4, bug #23740 (project gnustep):

Appears to have been resolved by a recent change to make code 64-bit safe in
NSBezierPath.m.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #23740] Getting "invalid type xxxx" when drawing

[Gregory John Casamento]

Update of bug #23740 (project gnustep):

Category:None => Gui/AppKit 
  Item Group:None => Bug
  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #16588] Can't ctrl-drag objects from a matrix.

[Gregory John Casamento]

Update of bug #16588 (project gnustep):

  Item Group: Bug => Change Request 


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #24109] gnustep-gui 0.14.0 does not build with LDFLAGS="-Wl, --as-needed -Wl, --no-undefined"

[Nicola Pero]

Update of bug #24109 (project gnustep):

Category:  Gui/AppKit => Makefiles  
  Item Group:None => Change Request 
  Status:   Fixed => In Progress
 Open/Closed:  Closed => Open   

___

Follow-up Comment #5:

I'm confused ... this looks like a request for a change in behaviour, not a
bug report ;-)

libgnustep-gui is not linked against libobjc.  That is done on purpose (eg
see #9920).
Only the final executable program is linked against all the libraries.  We
can discuss
if this is good or bad, but it's currently the expected behaviour; we need to
have a
longer discussion if we want to change it - it's not a bug fix, it's a
change. :-)

If we want to change it, I guess we want to change it for all ObjC libraries,
not just
gnustep-gui.  So the change would go in gnustep-make.  It doesn't really
make
much sense to change gnustep-gui only.

So ... what advantages would this change bring ?

Thanks

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #24109] gnustep-gui 0.14.0 does not build with LDFLAGS="-Wl, --as-needed -Wl, --no-undefined"

[Yavor Doganov]

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 correctly (there are some exceptions
like python extensions, etc.)

Many packages pass `-Wl,--as-needed' during build to strip unnecessary
dependencies, and additionally `-Wl,-z,defs' for extra safety.  It appears
that this has become common practice for Fedora and Mandriva too.  Superfluous
dependencies just make library transitions harder (and user's experience too,
as they install extra packages they don't need), and missing dependencies
cause mystical runtime failures that are sometimes hard to debug.  (The latter
is almost impossible in this case, but still...)

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep