bugGNUstep - Bugs: bug #13509, FFI problem on Gentoo

Group
 
 

bug #13509: FFI problem on Gentoo

Submitter:  Armando Di Cianno <fafhrd>
Submitted:  Wed 22 Jun 2005 07:59:18 PM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Wont Fix
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 16 Feb 2008 04:09:14 PM UTC, comment #7: 

There now is a separate supported version of libffi outside of gcc:

http://sourceware.org/libffi/

For this reason I think we may as well close this as a GNUstep bug report.

I am currently not using ffi, but will switch over to it as soon as pacakges are available for SuSE Linux. It would be great if somebody could check this new release in the meantime.

Fred Kiefer <FredKiefer>
Group Member
Tue 12 Jul 2005 05:25:49 PM UTC, comment #6: 

Other users are now experiencing this:

http://bugs.gentoo.org/show_bug.cgi?id=98711

I've suggested they use ffcall.  If this is related  somehow to newer computers/x86-chipsets and libffi, we're likely going to see a lot more of this.

Armando Di Cianno <fafhrd>
Sun 26 Jun 2005 10:21:55 AM UTC, comment #5: 

the ffi/ffcall argument is long as gnustep and free java itself. All say ffi should be better maintained, but in my experience it is not. Also the each supports platforms that the other one does not support. Also ffcall continually evolves, slowly, but at least it seems me almost more maintained than the libffi. Officially, libffi supports few platforms.
I personally started with ffcall and it works very well (wher ffcall works).
My x86 laptop tracks gentoo unstable and gnustep-cvs. I use ffcall (from portage) there and it works very well. TO be honest gentoo/x86 + ffcall + gnustep-cvs is the best-usable gnustep system I have.
On gentoo/pa-risc I use about the same setup (except that there I track gentoo stable) and it works well.

There are platforms (like netbsd/sparc) where both options are broken currently. But it is being worked on (on the ffcall side...)

Riccardo Mottola <rmottola>
Group Member
Thu 23 Jun 2005 05:38:57 PM UTC, comment #4: 

I seriaously doubt that the original summary of this bug was accurate since, while I don't use FFI myself, I'm aware that others use it without problems.  I've therefore changed the summary.

Given that you have one machine with it working and one without, I guess that it's a problem with configuration or specific libraries on one system.  Most likely anyone trying to track this down will need to see the results of the configure script from when you configured the base library on the problem machine.

I hope someone more familiar with FFI than I am can pick this up for you.

Richard Frith-Macdonald <CaS>
Group Member
Wed 22 Jun 2005 09:37:39 PM UTC, comment #3: 

and here is the /proc/cpuinfo of the machine that works:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 9
model name      : Intel(R) Pentium(R) M processor 1600MHz
stepping        : 5
cpu MHz         : 1587.900
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm pbe est tm2
bogomips        : 3145.72

Armando Di Cianno <fafhrd>
Wed 22 Jun 2005 09:36:14 PM UTC, comment #2: 

fwiw, here's the /proc/cpuinfo of the machine that fails:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 13
model name      : Intel(R) Pentium(R) M processor 2.00GHz
stepping        : 6
cpu MHz         : 1994.215
cache size      : 2048 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss tm pbe est tm2
bogomips        : 3956.73

Armando Di Cianno <fafhrd>
Wed 22 Jun 2005 08:15:38 PM UTC, comment #1: 

I am told now (pinskia on #gnustep) that libffi uses trampolines too, so both would be "evil" -- not that that is a valid argument if they are used safely.  Regardless, this bug is still a valid bug.

libffi would be a better option to use, in the long run, as it does seems to get pactches and updates being parked in and used by gcc; the status of ffcall seems a bit more ambiguous; the page hasn't been updated since, 1997, but the latest version 1.10, seems to be up to date.

Armando Di Cianno <fafhrd>
Wed 22 Jun 2005 07:59:18 PM UTC, original submission:  

History
-------

I maintain the GNUstep ebuilds for Gentoo.  When I first started doing that, I did some researching, and noticed some Gentoo security dev once mentioning that "ffcall does evil things" in an email.  I emailed the security people and asked them why ffcall was "evil".  Basically, the response was that ffcall uses trampolines, which aren't the safest way to go.  Since then, libffi has been the only option to use, since it did not use trampolines.

Until yesterday, I have never had a complete breakdown of GNUstep, although minor issues where attributed to libffi/GNUstep/GSFFIInvocation/mframe.

Bug
---
Yesterday, I finished up my base install of a new, nice, fast dev box I purchased.  I installed my GNUstep ebuilds.  I installed GWorkspace.  I installed GNUMail.

GWorkspace crashes when I drag a folder icon to the "top bar" (to createa a "shortcut").  GNUMail crashes when I click in a textbox (to configure email accounts.  Both crash with a SIGSEGV.

I attempted to use gdb to set breakpoints and see what was crashing it, but no matter what I break'd on, the stack was completely blown.  Thinking it was gpbs and/or gdnc and/or gdomap, I ran all in the foreground.  I used LD_DEBUG.  I didn't start them at login, and had the applications launch them.  Nothing helped.

I decided to at least try ffcall, regardless of if I would continue using it -- ffcall removes all of the problems.

Request
-------
Depending on if GNUstep "fears" trampolines in ffcall, or the mess that is the GSFFIInvocation code, one of these packages should be chosen.

Summary
-------
GNUstep use of libffi is completely broken, and needs to be fixed, or removed, as it is likely the cause of most "sketchy" bugs with core GNUstep packages (that I have ever experienced).

Armando Di Cianno <fafhrd>

 

(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 (Updated the item)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  •  

    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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-02-19 rmottola Open/ClosedIn Test Closed
    2008-02-16 FredKiefer StatusNone Wont Fix
        Open/ClosedOpen In Test
    2005-06-23 CaS SummaryGNUstep use of FFI is completely broken FFI problem on Gentoo

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code