bugGNUstep - Bugs: bug #23709, NSProxy test fails on Ubuntu with...

Group
 
 

bug #23709: NSProxy test fails on Ubuntu with ffcall

Submitter:  Fred Kiefer <FredKiefer>
Submitted:  Wed 25 Jun 2008 11:20:28 PM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 16 Jun 2010 08:19:37 AM UTC, comment #5: 

Closing this ... since ffi works and ffcall is deprecated.

Richard Frith-Macdonald <CaS>
Group Member
Thu 20 May 2010 07:35:31 AM UTC, comment #4: 

Is this still a problem wfor you? There were several fixes and there is both a new release of ffcall and one of libffi.

for me, on debian x86 32bit with libffi, all NSProxy tests pass

--- Running tests in NSProxy ---

      3 COMPLETED
     33 PASS

Riccardo Mottola <rmottola>
Group Member
Sat 17 Oct 2009 06:20:29 PM UTC, comment #3: 

I think the recent changes to ffi should have fixed this ... please could you retest.

Richard Frith-Macdonald <CaS>
Group Member
Sat 05 Jul 2008 10:11:40 PM UTC, comment #2: 

I did some more debugging of where the problem in the original code comes from. It happens when an NSInvovation started as a separate thread tries to return a boolean value. This works sometimes (mostly the first time) but fails later.

In my last tests this failed just the same for ffi and ffcall, but then I am not that sure how much my NSLog() calls interact with the invocation handling. For example if the issue was caused by the usage of uninitialized memory then this calls could make a difference.

Fred Kiefer <FredKiefer>
Group Member
Thu 26 Jun 2008 04:55:35 AM UTC, comment #1: 

I added these tests just recently, with the main intention to compare ffcall with libffi.

These tests to test boarder line yet to my understanding valid cases.  The attempt to pass structs as parameters:

GSFinePoint:
typedef struct _GSFinePoint GSFinePoint;
struct _GSFinePoint
{
  double x;
  double y;
};
GSFinePoint

typedef struct _GSBitField GSBitField;
struct _GSBitField
{
  unsigned int first:1;
  unsigned int unused:1;
  unsigned int second:1;
};
GSBitField


I'm not sure if those cases ever worked.  Most of the time such structs are passed by reference and not by value.  Yet I do believe that a correctly working implementation should pass.  But I can verify that when I started testing them on different platforms that the last test segfaulted on the 64-bit case.

IIRC, this failure is the result of incorrect/missing layout information provided by the runtime which we are not ready to handle.  I'm not sure if it may have been correct with very old versions of the GNU runtime before the new ObjC features were added and the encoding signatures of GCC changed.

IOW, we have real bugs here but they should not be considered regressions (in GNUstep) per se.  If you say that your Ubuntu used to work with ffcall and now it doesn't, then that is a regression.  Yet these tests are not necessarily related.

David Ayers <ayers>
Group Member
Wed 25 Jun 2008 11:20:28 PM UTC, original submission:  

I am using Ubuntu 8.04 (32-bit) in a VMWareFusion environment. I jsut update to this release and also updated GNUstep to latest SVN. Now an application that use to work give segmentation faults for both ffi and ffcall.

When trying to trac down the problem for ffcall further I ran the testsuite for base and got the following problem there (This works fine on my desktop computer):

ubuntu@ubuntu:/usr/src/gnustep/modules/tests/testsuite/base/NSProxy$ gdb obj/test01
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) r
Starting program: /usr/src/gnustep/modules/tests/testsuite/base/NSProxy/obj/test01
[Thread debugging using libthread_db enabled]
[New Thread 0xb77bb6b0 (LWP 895)]
PASS: Proxy signed char
PASS: Proxy unsigned char
PASS: Proxy signed short
PASS: Proxy unsigned short
PASS: Proxy singed int
PASS: Proxy unsigned int
PASS: Proxy signed long
PASS: Proxy unsigned long
PASS: Proxy signed long long
PASS: Proxy unsigned long long
PASS: Proxy float
PASS: Proxy float
PASS: Proxy id
PASS: Proxy enum
PASS: Proxy NSRange
PASS: Proxy NSPoint
PASS: Proxy NSDecimal
FAIL: Proxy GSFinePoint

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb77bb6b0 (LWP 895)]
0xb7c4c0f8 in mframe_next_arg (typePtr=0x0, info=0x809f1b0,
    outTypes=0x809f1f9 "") at mframe.m:229
229       switch (*typePtr)
(gdb) bt
#0  0xb7c4c0f8 in mframe_next_arg (typePtr=0x0, info=0x809f1b0,
    outTypes=0x809f1f9 "") at mframe.m:229
#1  0xb7d3e06e in -[NSMethodSignature(GNUstep) methodInfo] (self=0x809f108,
    _cmd=0xb7f86658) at NSMethodSignature.m:189
#2  0xb7e00b08 in -[GSFFCallInvocation initWithMethodSignature:] (
    self=0x809f170, _cmd=0xb7f866a8, aSignature=0x809f108)
    at GSFFCallInvocation.m:547
#3  0xb7e0270a in GSInvocationCallback (callback_data=0x80710b8,
    args=0xbfe52c94) at GSFFCallInvocation.m:957
#4  0xb785d6d5 in __vacall_r () from /usr/lib/libcallback.so.0
#5  0x080710b8 in ?? ()
#6  0xb7a3f450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#7  0x08048ba1 in _start ()




The config.log for ffi and ffcall reads like this:
configure:16312: checking ffi.h presence
configure:16327: gcc -E  -I/usr/GNUstep/System/Library/Headers conftest.c
configure:16333: $? = 0
configure:16347: result: yes
configure:16375: checking for ffi.h
configure:16382: result: yes
configure:16408: checking callback.h usability
configure:16425: gcc -c -g -O2  -I/usr/GNUstep/System/Library/Headers conftest.c >&5
configure:16431: $? = 0
configure:16445: result: yes
configure:16449: checking callback.h presence
configure:16464: gcc -E  -I/usr/GNUstep/System/Library/Headers conftest.c
configure:16470: $? = 0
configure:16484: result: yes
configure:16512: checking for callback.h
configure:16520: result: yes
configure:16549: checking for forwarding callback in runtime
configure:16560: gcc -c -g -O2  -I/usr/GNUstep/System/Library/Headers -fgnu-runtime -x objective-c conftest.c >&5
In file included from conftest.c:1:
./config/config.forward2.m: In function 'main':
./config/config.forward2.m:5: error: '__objc_msg_forward2' undeclared (first use in this function)
./config/config.forward2.m:5: error: (Each undeclared identifier is reported only once
./config/config.forward2.m:5: error: for each function it appears in.)
configure:16566: $? = 1
configure: failed program was:
| #include "./config/config.forward2.m"
configure:16596: gcc -c -g -O2  -I/usr/GNUstep/System/Library/Headers -fgnu-runtime -x objective-c conftest.c >&5
configure:16602: $? = 0
configure:16617: result: yes
configure:16625: checking FFI library usage
configure:16716: gcc -o conftest -g -O2  -I/usr/GNUstep/System/Library/Headers  -L/usr/GNUstep/System/Library/Libraries conftest.c -lcallback -lavcall -lnsl -ldl  -lz >&5
configure:16722: $? = 0
configure:16739: result: ffcall
configure:16751: checking if ffcall trampolines work
configure:16765: gcc -o conftest -g -O2  -I/usr/GNUstep/System/Library/Headers  -L/usr/GNUstep/System/Library/Libraries conftest.c -lcallback -lavcall -lnsl -ldl  -lz >&5
configure:16768: $? = 0
configure:16774: ./conftest
configure:16777: $? = 0
configure:16792: result: yes


And to make it complete. My original error was:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb713a6c0 (LWP 27073)]
0xb77965c4 in objc_msg_lookup () from /usr/lib/libobjc.so.2
(gdb) bt
#0  0xb77965c4 in objc_msg_lookup () from /usr/lib/libobjc.so.2
#1  0xb79ec040 in GSInvocationCallback (callback_data=0xb7b87330,
    args=0xbff89694) at GSFFCallInvocation.m:1050
#2  0xb72bb6d5 in __vacall_r () from /usr/lib/libcallback.so.0
#3  0xb7b87330 in returnTypeInfo ()
   from /usr/GNUstep/System/Library/Libraries/libgnustep-base.so.1.17
#4  0xbff89694 in ?? ()
#5  0x0805c376 in -[MainController awakeFromNib] (self=0x8562e28,
    _cmd=0xb7f3e508) at Source/MainController.m:199


Fred Kiefer <FredKiefer>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rmottola (Posted a comment)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by ayers (Posted a comment)
  • -email is unavailable- added by FredKiefer (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-06-16 CaS Open/ClosedIn Test Closed
    2009-10-17 CaS Open/ClosedOpen In Test

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code