Thread: Assertion Fail error

  1. #1
    Registered User TheEngineer's Avatar
    Join Date
    Aug 2009
    Posts
    50

    Assertion Fail error

    Trying to compile a program with 2 source files and several headers, get the following error when I try to make:

    Code:
    /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: BFD (GNU Bi
    nutils) 2.19.51.20090704 assertion fail /netrel/src/binutils-2.19.51-1/bfd/coff-
    i386.c:525
    It shows up about 7 times and then exits.

    Looking around, it seems that assertion fail errors come from mostly bad pointers or misplaced files. How do I tell which is which?


    I also found that assertion fail errors were a common bug for binutils 2.18 but was supposed to be fixed for 2.19?

  2. #2
    Registered User claudiu's Avatar
    Join Date
    Feb 2010
    Location
    London, United Kingdom
    Posts
    2,094
    Can you post your source code?
    1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
    2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
    3. Get rid of conio.h and other antiquated DOS crap headers.
    4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.

  3. #3
    Registered User TheEngineer's Avatar
    Join Date
    Aug 2009
    Posts
    50
    Quote Originally Posted by claudiu View Post
    Can you post your source code?

    I can, but it is 650+ lines. For now I am just trying to narrow down the source of the error, looking for possible causes

  4. #4
    Registered User claudiu's Avatar
    Join Date
    Feb 2010
    Location
    London, United Kingdom
    Posts
    2,094
    Well it's really hard to tell where your problem is coming from. Try using a debugger and narrow down the part of the code where it's crashing. Then post that over here.
    1. Get rid of gets(). Never ever ever use it again. Replace it with fgets() and use that instead.
    2. Get rid of void main and replace it with int main(void) and return 0 at the end of the function.
    3. Get rid of conio.h and other antiquated DOS crap headers.
    4. Don't cast the return value of malloc, even if you always always always make sure that stdlib.h is included.

  5. #5
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    I'd take a stab that you're passing source files directly to the linker.

    Post a makefile / command lines you're using to build with.

    Also, if you're linking with libraries you've downloaded, you might have to recompile them yourself.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  6. #6
    Registered User TheEngineer's Avatar
    Join Date
    Aug 2009
    Posts
    50
    Quote Originally Posted by Salem View Post
    I'd take a stab that you're passing source files directly to the linker.

    Post a makefile / command lines you're using to build with.

    Also, if you're linking with libraries you've downloaded, you might have to recompile them yourself.

    Here is the Makefile I am using:

    Code:
    bin_PROGRAMS = Ddx
                  
    
    SOURCE_DIR = $(top_srcdir)
    SOURCE_INCLUDE_DIR = $(SOURCE_DIR)/../../include
    SOURCE_COMMON_DIR = $(SOURCE_DIR)/../../common
    SOURCE_LDSCRIPT_DIR = $(SOURCE_DIR)
    
    BUILD_DIR = $(top_builddir)
    BUILD_PROM_DIR = $(BUILD_DIR)
    
    CC=gcc
    AM_CFLAGS=-c -Wall 
    AM_LDFLAGS=
    SOURCES=$(SOURCE_DIR)/Ddx.c $(SOURCE_DIR)/Esx.c
    OBJECTS=$(SOURCES:.c=.o)
    EXE=Ddx
    
    all: $(EXE)
    	
    $(EXE): $(OBJECTS) 
    	$(CC) $(SOURCES) -o $@
    
    %.o: %.c
    	$(CC) $(AM_CFLAGS) $< -o $@
    And the commands are as follows:

    Code:
    $>autoreconf -fis
    $>cd to build directory
    $> ../configure
    $>make

    And this is a complete output of what I get:

    Code:
    gcc ../Ddx.c ../Esx.c -o Ddx
    ../Ddx.c: In function `main':
    ../Ddx.c:92: warning: return type of `main' is not `int'
    /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: BFD (GNU Bi
    nutils) 2.19.51.20090704 assertion fail /netrel/src/binutils-2.19.51-1/bfd/coff-
    i386.c:525
    /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: BFD (GNU Bi
    nutils) 2.19.51.20090704 assertion fail /netrel/src/binutils-2.19.51-1/bfd/coff-
    i386.c:525
    /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: BFD (GNU Bi
    nutils) 2.19.51.20090704 assertion fail /netrel/src/binutils-2.19.51-1/bfd/coff-
    i386.c:525
    /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: BFD (GNU Bi
    nutils) 2.19.51.20090704 assertion fail /netrel/src/binutils-2.19.51-1/bfd/coff-
    i386.c:525
    /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: BFD (GNU Bi
    nutils) 2.19.51.20090704 assertion fail /netrel/src/binutils-2.19.51-1/bfd/coff-
    i386.c:525
    /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: BFD (GNU Bi
    nutils) 2.19.51.20090704 assertion fail /netrel/src/binutils-2.19.51-1/bfd/coff-
    i386.c:525
    /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: BFD (GNU Bi
    nutils) 2.19.51.20090704 assertion fail /netrel/src/binutils-2.19.51-1/bfd/coff-
    i386.c:525
    /tmp/ccwmcxsU.o:Esr.c:(.text+0x58): undefined reference to `_BitSet'
    /tmp/ccwmcxsU.o:Esr.c:(.text+0xd0): undefined reference to `_BitSet'
    collect2: ld returned 1 exit status
    make: *** [Ddx] Error 1

  7. #7
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    The only odd thing about your make file is the lack of incremental compilation.

    Code:
    $(EXE): $(OBJECTS) 
    	$(CC) $(SOURCES) -o $@
    you build everything every time.


    Code:
    $(EXE): $(OBJECTS) 
    	$(CC) $(OBJECTS) -o $@
    allows make to use the %.o: %.c rule to compile each file independently.

    It would be interesting to see what kind of file your .o files were (use the objdump tool).

    I take it from the names that you're using a cygwin environment?
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  8. #8
    Registered User TheEngineer's Avatar
    Join Date
    Aug 2009
    Posts
    50
    Quote Originally Posted by Salem View Post
    The only odd thing about your make file is the lack of incremental compilation.

    Code:
    $(EXE): $(OBJECTS) 
    	$(CC) $(SOURCES) -o $@
    you build everything every time.


    Code:
    $(EXE): $(OBJECTS) 
    	$(CC) $(OBJECTS) -o $@
    allows make to use the %.o: %.c rule to compile each file independently.

    It would be interesting to see what kind of file your .o files were (use the objdump tool).

    I take it from the names that you're using a cygwin environment?

    Is there a better form for the makefile? I just used a template sort of thing.

    What info (flags) do you want to see from the objdump? Here's the output from objdump -s Esx.o:


    Code:
    $ objdump -s Esx.o
    
    Esx.o:     file format pe-i386
    
    Contents of section .text:
     0000 5589e556 5383ec30 8b45088b 550c8b4d  U..VS..0.E..U..M
     0010 108b5d14 668945f4 668955f0 884dec88  ..].f.E.f.U..M..
     0020 5de80fb6 4de8b80f 0000002a 45ec0fb6  ]...M......*E...
     0030 d80fb775 f4b81000 00002a45 e80fb6c0  ...u......*E....
     0040 0fb755f0 894c2410 895c240c 89742408  ..U..L$..\$..t$.
     0050 89442404 891424e8 00000000 83c4305b  .D$...$.......0[
     0060 5e5dc355 89e55383 ec348b45 088b550c  ^].U..S..4.E..U.
     0070 8b4d108b 5d146689 45f86689 55f4884d  .M..].f.E.f.U..M
     0080 f0885dec 807df00f 7510807d ec10750a  ..]..}..u..}..u.
     0090 0fb745f4 668945ea eb3e0fb6 4decb810  ..E.f.E..>..M...
     00a0 0000002a 45ec0fb6 d8b80f00 00002a45  ...*E.........*E
     00b0 f00fb6c0 0fb755f4 894c2410 895c240c  ......U..L$..\$.
     00c0 c7442408 00000000 89442404 891424e8  .D$......D$...$.
     00d0 00000000 668945ea 0fb745ea 83c4345b  ....f.E...E...4[
     00e0 5dc35589 e583ec0c 8b45148b 55188b4d  ].U......E..U..M
     00f0 1c8845fc 8855f866 894df48b 55100fb6  ..E..U.f.M..U...
     0100 45fc8802 8b55100f b645f888 42018b55  E....U...E..B..U
     0110 100fb745 f4668942 028b5510 8b450889  ...E.f.B..U..E..
     0120 42048b55 108b450c 894208c9 c35589e5  B..U..E..B...U..
     0130 57565383 ec348b45 108945c0 8b55148b  WVS..4.E..E..U..
     0140 4d188b5d 1c8b7520 8b7d248b 45288945  M..]..u .}$.E(.E
     0150 cc8b452c 8945c88b 45348945 c40fb645  ..E,.E..E4.E...E
     0160 c08845f0 8855ec66 894de866 895de466  ..E..U.f.M.f.].f
     0170 8975e066 897ddc0f b745cc66 8945d80f  .u.f.}...E.f.E..
     0180 b745c866 8945d40f b745c466 8945d00f  .E.f.E...E.f.E..
     0190 b655f08b 450c8810 0fb655ec 8b450c88  .U..E.....U..E..
     01a0 50018b55 0c0fb745 e8668942 028b550c  P..U...E.f.B..U.
     01b0 8b450889 42048b55 0c8b4530 89420c0f  .E..B..U..E0.B..
     01c0 bf45dcc1 e00689c2 0fb745d8 83e03f09  .E........E...?.
     01d0 d089c28b 450c8850 080fb745 d489c28b  ....E..P...E....
     01e0 450c8850 090fbf45 e4c1e00e 89c20fbf  E..P...E........
     01f0 45e083e0 3fc1e008 09d089c2 80cafd8b  E...?...........
     0200 450c6689 500a83c4 345b5e5f 5dc35589  E.f.P...4[^_].U.
     0210 e583ec0c 8b45108b 55148b4d 188845fc  .....E..U..M..E.
     0220 8855f866 894df48b 550c0fb6 45fc8802  .U.f.M..U...E...
     0230 8b550c0f b645f888 42018b55 0c0fb745  .U...E..B..U...E
     0240 f4668942 028b550c 8b450889 42048b55  .f.B..U..E..B..U
     0250 0c8b451c 8942088b 550c8b45 2089420c  ..E..B..U..E .B.
     0260 c9c39090                             ....


    And yes, I am using Cygwin.

  9. #9
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    > Esx.o: file format pe-i386
    This is what I was looking for.

    Kinda weird really, since the linker seems to be looking for coff files.

    Did you get all the tools from the same place?
    It seems strange that the compiler and linker disagree "out of the box".
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  10. #10
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    COFF and PE are related on Windows, I think that's a red herring.

    Looks like you've just got a buggy binutils.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  11. #11
    Registered User TheEngineer's Avatar
    Join Date
    Aug 2009
    Posts
    50
    Quote Originally Posted by brewbuck View Post
    COFF and PE are related on Windows, I think that's a red herring.

    Looks like you've just got a buggy binutils.
    Hmm...I seem to be able to compile other programs though. I suppose I will try to find and install the latest version of binutils?

  12. #12
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    > I seem to be able to compile other programs though
    Yeah, that's what I would have guessed.

    Is there anything peculiar about your source code?
    - was it downloaded from somewhere?
    - does it have any odd #pragma of __attribute__ syntax? (also check any local header files)
    - what about inline assembler?

    Do the objdump thing on known good .o files and .exe files, and see what formats they are.

    Also compiling with the -v option allows you to see a lot more of what the compiler is doing (especially what options it passes to the linker). Compare with known good compilation runs.

    > I can, but it is 650+ lines. For now I am just trying to narrow down the source of the error, looking for possible causes
    So if you cut the body out of each function - except for necessary declarations for a return type/value say, would it still throw the same error?
    The result would be easier to post if that were the case.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  13. #13
    Registered User TheEngineer's Avatar
    Join Date
    Aug 2009
    Posts
    50
    Quote Originally Posted by Salem View Post
    > I seem to be able to compile other programs though
    Yeah, that's what I would have guessed.

    Is there anything peculiar about your source code?
    - was it downloaded from somewhere?
    - does it have any odd #pragma of __attribute__ syntax? (also check any local header files)
    - what about inline assembler?

    Do the objdump thing on known good .o files and .exe files, and see what formats they are.
    Doing objdump on working files shows that the files are of the same form.

    I do have __attribute__ syntax, of the following form:

    Code:
    __attribute__ ((section ("GPARMS"))) struct ConfigTableType ConfigTable = {
        1, 3, 0x1F, 0x1F, 0xF, 0xF, &main};
    But this code is in several files and does not cause a problem elsewhere.

    I suspect the inline assembler is the issue. The source files were written for an m68k processor and had to be converted to be compiled for the i686. The only thing I had to change was the inline assembly in one of the files, which I may have done incorrectly. Here is the original code:

    Code:
    #define REG	__asm__ volatile ("move.b	#0x1,-(%sp)\n");
    #define DREG	__asm__ volatile ("move.b	#0x0,-(%sp)\n");
    
    #define REG_AP(mr,reg_flag) \
    	({ \
    		reg_flag \
    		__asm__ volatile ("pea		%0\n" :"=m"(*mr)); \
    		__asm__ volatile ("jsr		0x8000\n"); \
    	})
    
    #define SCH_IO(mi,follow,rcode) \
    	({ \
    		__asm__ volatile ("pea		%0\n" :"=m"(*mi)); \
    		__asm__ volatile ("pea		%0\n" :"=m"(*follow)); \
    		__asm__ volatile ("pea		%0\n" :"=m"(*rcode)); \
    		__asm__ volatile ("jsr	0x8200\n"); \
    	})
    
    #define SCH_IO_NO_FOLLOW_ON(mi,rcode) \
    	({ \
    		__asm__ volatile ("pea		%0\n" :"=m"(*mi)); \
    		__asm__ volatile ("move.l	#0x0,-(%sp)\n"); \
    		__asm__ volatile ("pea		%0\n" :"=m"(*rcode)); \
    		__asm__ volatile ("jsr	0x8200\n"); \
    	})
    And this is what I changed it to:

    Code:
    #define REG	__asm__ __volatile__("movb	$0x1,(%ESP)\n");
    #define DREG	__asm__ __volatile__("movb	$0x0,(%ESP)\n");
    
    #define G_AP(mr,reg_flag) \
      ({ \
    		reg_flag \
    		__asm__ __volatile__("push  %0\n" :"=m"(*mr)); \
      	__asm__ __volatile__("call  0x8000\n"); \
      })
    
    #define SCHED_IO(mi,follow,rcode) \
    	({ \
    		__asm__ __volatile__("push	%0\n" :"=m"(*mi)); \
    		__asm__ __volatile__("push	%0\n" :"=m"(*follow)); \
    		__asm__ __volatile__("push  %0\n" :"=m"(*rcode)); \
    		__asm__ __volatile__("call	0x8200\n"); \
    	})
    
    #define SCHED_IO_NO_FOLLOW_ON(mi,rcode) \
    	({ \
    		__asm__ __volatile__("push  %0\n" :"=m"(*mi)); \
    		__asm__ __volatile__("movl  (%ESP),$0x0\n"); \
    		__asm__ __volatile__("push  %0\n" :"=m"(*rcode)); \
    		__asm__ __volatile__("call	0x8200\n"); \
    	})

    I had previous problems with this step and it's really the only code I have changed from the working version, so I think it is the main cause of the issue

  14. #14
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    The call to absolute addresses would be a problem.

    The first being that the linker is producing relocatable images, and it might be upset by an absolute address (just a guess, but download the binutils source and look at the source line of the assert to see what it is actually trying to do, and what is bad at that point).

    Even if it compiled, actually calling that address at run-time would NOT do what you wanted.
    Were these originally traps into the OS (or embedded RTOS) running on your m68k ?

    You need to figure out what is the functional replacement for these asm inserts; not a minimal literal translation.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  15. #15
    Registered User TheEngineer's Avatar
    Join Date
    Aug 2009
    Posts
    50
    Quote Originally Posted by Salem View Post
    The call to absolute addresses would be a problem.

    The first being that the linker is producing relocatable images, and it might be upset by an absolute address (just a guess, but download the binutils source and look at the source line of the assert to see what it is actually trying to do, and what is bad at that point).

    Even if it compiled, actually calling that address at run-time would NOT do what you wanted.
    Were these originally traps into the OS (or embedded RTOS) running on your m68k ?

    You need to figure out what is the functional replacement for these asm inserts; not a minimal literal translation.
    Thanks, I'll look into it some more

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Getting an error with OpenGL: collect2: ld returned 1 exit status
    By Lorgon Jortle in forum C++ Programming
    Replies: 6
    Last Post: 05-08-2009, 08:18 PM
  2. Testing some code, lots of errors...
    By Sparrowhawk in forum C Programming
    Replies: 48
    Last Post: 12-15-2008, 04:09 AM
  3. how do you resolve this error?
    By -EquinoX- in forum C Programming
    Replies: 32
    Last Post: 11-05-2008, 04:35 PM
  4. We Got _DEBUG Errors
    By Tonto in forum Windows Programming
    Replies: 5
    Last Post: 12-22-2006, 05:45 PM
  5. Post...
    By maxorator in forum C++ Programming
    Replies: 12
    Last Post: 10-11-2005, 08:39 AM