Bug 787396 - Possible gcc bug with objective C instance allocation
Summary: Possible gcc bug with objective C instance allocation
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 773185
TreeView+ depends on / blocked
 
Reported: 2012-02-04 19:28 UTC by Bruno Wolff III
Modified: 2012-02-06 15:37 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-06 15:37:54 UTC
Type: ---


Attachments (Terms of Use)
This is the patch used to fix the build after the mass rebuild attempt failed. (5.71 KB, patch)
2012-02-05 15:34 UTC, Bruno Wolff III
no flags Details | Diff

Description Bruno Wolff III 2012-02-04 19:28:02 UTC
Description of problem:
I made a few changes to raidem to get it to with gcc 4.7 in rawhide. However it is now segfaulting while allocating an instance of Token. The segfault happens in __objc_responds_to. raidem did work when built from older versions of gcc. It doesn't seem to be something that would be due to raidem code, though I don't know objective c well enough to be sure. The only thing that seems unusual about the Token type is that it contains a union struct.

Version-Release number of selected component (if applicable):
gcc-4.7.0-0.10.fc17.i686
raidem-0.3.1-19.fc17

How reproducible:


Steps to Reproduce:
1. gdb /usr/bin/raidem
2. run
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Aravind vijayan 2012-02-05 05:40:13 UTC
Thank you for your report,

                         "I made a few changes to raidem to get it to with gcc 4.7 in rawhide" -- please attach the changes you have made. Consider adding data on " Actual results: Expected results:" fields ,and the stack trace.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 2 Bruno Wolff III 2012-02-05 15:31:25 UTC
There isn't much to say about the expected results. The game segfaults before any visible output is displayed by the game.
The changes included to get the game to build for gcc 4.7 are already in the latest version (0.3.1-19.fc17) of raidem in Fedora, but I'll attach the patch that is included in the srpm.
The traceback from gdb is:
Program received signal SIGSEGV, Segmentation fault.
__objc_responds_to (sel=<optimized out>, object=0x8136460)
    at /usr/src/debug/gcc-4.7.0-20120126/libobjc/sendmsg.c:398
398	  res = sarray_get_safe (dtable, (size_t) sel->sel_id);
(gdb) where
#0  __objc_responds_to (sel=<optimized out>, object=0x8136460)
    at /usr/src/debug/gcc-4.7.0-20120126/libobjc/sendmsg.c:398
#1  __objc_forward (object=0x8136460, sel=0x8136430, args=0xbfffec90)
    at /usr/src/debug/gcc-4.7.0-20120126/libobjc/sendmsg.c:905
#2  0x41138d7c in __objc_word_forward (rcv=0x8136460, op=0x8136430)
    at /usr/src/debug/gcc-4.7.0-20120126/libobjc/sendmsg.c:844
#3  0x0809814d in ?? ()
#4  0x0804f0d0 in ?? ()
#5  0x0804bda3 in ?? ()
#6  0x4c4ce645 in __libc_start_main (main=0x804bd30, argc=1, 
    ubp_av=0xbfffef84, init=0x80c5dd0, fini=0x80c5e40, 
    rtld_fini=0x4c49d920 <_dl_fini>, stack_end=0xbfffef7c) at libc-start.c:226
#7  0x0804d8e9 in ?? ()

This shows where in the objective C library this is dying. In raidem this is happening when doing an alloc for a Token object. The token code is in include/seborrhea/token.h and src/seborrhea/token.m.

The Token structure is:
@interface Token: Object
{
    enum TOKEN_TYPE type;
    union {
	struct {
	    char *str;
	    unsigned int len;
	} string;
	struct {
	    int num;
	} fixnum;
    } data;
}

Comment 3 Bruno Wolff III 2012-02-05 15:34:19 UTC
Created attachment 559471 [details]
This is the patch used to fix the build after the mass rebuild attempt failed.

Comment 4 Aravind vijayan 2012-02-06 00:28:38 UTC

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 5 Bruno Wolff III 2012-02-06 01:11:52 UTC
Why did you close this bug?

Comment 6 Aravind vijayan 2012-02-06 02:00:09 UTC
Apologizing i think this bug was fixed,
> This is the patch used to fix the build after the mass rebuild attempt failed.





-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 7 Bruno Wolff III 2012-02-06 03:03:06 UTC
No. That patch was used to fix FTBFS between raidem-0.3.1-19.fc17 and raidem-0.3.1-19.fc19. However after raidem was building successfully it didn't actually work. I suspect this is a problem with gcc, but don't know for sure.

Comment 8 Jakub Jelinek 2012-02-06 14:04:13 UTC
I guess this is related to
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00254.html
The segfault is because:
901	  /* First try if the object understands forward::.  */
902	  if (! frwd_sel)
903	    frwd_sel = sel_get_any_uid ("forward::");
904	
905	  if (__objc_responds_to (object, frwd_sel))
in __objc_forward has frwd_sel NULL when calling __objc_responds_to, supposedly because -forward:: has been removed from Object.m.
Please talk to Nicola Pero on how you should adjust your code.

Comment 9 Bruno Wolff III 2012-02-06 15:37:54 UTC
Thanks for the help.
I think this means that raidem is using a depreciated feature and this isn't actually a gcc bug, so I am going to close this and just track the issue through the raidem bug.


Note You need to log in before you can comment on or make changes to this bug.