LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 05-24-2006, 11:00 PM   #1
cris123
LQ Newbie
 
Registered: May 2006
Posts: 3

Rep: Reputation: 0
Question run well in vc++ but not in g++


hello everyone

i have a problem with my source code..

it compiled well and runs well in visual c++ 6.0 (at window xp)

but it doesn't run in g++ 4.0, (ubuntu)

g++ compile my source well but when i excute the output file,

segmentation violation happens.

the library i used are just simple : stdio, math, stdlib


it is very strange, for the same source code,, vc++ works well and g++ do not.

anyone have same experince?

are there any difference between (vc++ and g++) or (window and linux)?

any sugesstion to solve this problem..? plz help

ps. my source code is over 500 lines.. so i didn't attatch it here.

Last edited by cris123; 05-24-2006 at 11:55 PM.
 
Old 05-25-2006, 01:25 AM   #2
daihard
Member
 
Registered: Jul 2003
Location: Seattle, WA
Distribution: Kubuntu 14.04 LTS
Posts: 915

Rep: Reputation: 34
Quote:
Originally Posted by cris123
are there any difference between (vc++ and g++) or (window and linux)?

any sugesstion to solve this problem..? plz help
There are certainly differences between the two environments. The C/C++ standards allow for varieties in implementation.

When a segmentation fault occurs, it usually implies a memory problem (i.e. using an un-initialized pointer, freeing a pointer twice, memory overflow, etc). I'd suggest that you run the program under the debugger and see where the segfault occurs. The name of the GNU debugger is "gdb." You can run it like "gdb <prog_name>". Make sure you compile your program with "-g" so debugging symbols will be compiled in.
 
Old 05-25-2006, 01:44 AM   #3
cris123
LQ Newbie
 
Registered: May 2006
Posts: 3

Original Poster
Rep: Reputation: 0
memory problem.. and using gdb..

before using gdb ,, i should RTF about gdb first

thanx!
 
Old 05-25-2006, 02:20 AM   #4
daihard
Member
 
Registered: Jul 2003
Location: Seattle, WA
Distribution: Kubuntu 14.04 LTS
Posts: 915

Rep: Reputation: 34
Quote:
Originally Posted by cris123
memory problem.. and using gdb..

before using gdb ,, i should RTF about gdb first

thanx!
Debugger is your friend. It may seem like a difficult tool to use at first, but once you get the hang of it, you will find gdb to be an invaluable tool that helps you find and fix problems in your code.
 
Old 05-25-2006, 02:51 AM   #5
dmail
Member
 
Registered: Oct 2005
Posts: 970

Rep: Reputation: Disabled
Quote:
it compiled well and runs well in visual c++ 6.0 (at window xp)
This may be so, but it still may not be valid c++ code. VC6 was released before standardisation (1998?), drop it like a bag of hot potatoes.

Quote:
ps. my source code is over 500 lines.. so i didn't attatch it here.
you could post the code at the url in my sign and post back here the url of your code, that may well be better.(see Jeremy, it is useful )
 
Old 05-25-2006, 01:43 PM   #6
paulsm4
LQ Guru
 
Registered: Mar 2004
Distribution: SusE 8.2
Posts: 5,863
Blog Entries: 1

Rep: Reputation: Disabled
Gdb "cheat sheet", etc

VC++ is, in general, a lot more lax and a lot less conforming than GCC.

To use "gdb", you must compile/link with "-g".

Here's a quick "cheat sheet" for some of the main gdb commands:
Code:
  gdb myprog   # Start program in debugger
    b main     # Set breakpoint in function "main()"
    r abc      # "run" program with cmd-line arguments "abc"
    next       # "n": Single step (over functions)
    step       # "s": Single step (into functions)
    where      # Get stack traceback of current location in program
    p i        # Print the value of variable "i"
    del 1      # Delete breakpoint #1 (your "b main")
    h          # Gdb "help"
    q          # "Quit": Exit debugger
And here's a sample program with one illustration of how different platforms can treat arrays and pointer storage allocation differently (which might be precisely your problem):
Code:
/*
 * Test SEGV
 *
 * 1) Microsoft compile/run:
 *    ---------------------
 *    - cl x.cpp => OK
 *    - x 123 =>
 *        Original strings: s1= abc, s2= abc...
 *        Updated strings: s1= 123, s2= 123...
 *        
 *    - x 123456 =>
 *        Original strings: s1= abc, s2= abc...
 *      <= FIRST ONE OK, SECOND DIES IMMEDIATELY
 *
 * 2) G++ compile/debug:
 *    -----------------
 *    - g++ -g -Wall -pedantic -o x x.cpp
 *      <= BE SURE TO INCLUDE "-g" SWITCH, FOR DEBUG INFO
 *    - gdb x
 *      (gdb) run
 *      <= THIS WILL PROMPT FOR USAGE
 *      (gdb) r 123
 *        Starting program: /home/paulsm/proj/temp/x 123
 *        Original strings: s1= abc, s2= abc...
 *        Program received signal SIGSEGV, Segmentation fault.
 *        0x4017f3d6 in strcpy () from /lib/tls/libc.so.6 *        
 *        <= THIS DIES...
 *      (gdb) where
 *        <= "WHERE" TELLS US OUR CURRENT TRACEBACK
 *        #0  0x4017f3d6 in strcpy () from /lib/tls/libc.so.6
 *        #1  0x08048518 in main (argc=2, argv=0xbffff3f4) at x.cpp:42
 *      (gdb) list
 *        <= "LIST" PRINTS THE CURRENT SOURCE
 *        42         strcpy (s1, argv[1]);
 *        43         strcpy (s2, argv[1]);
 *        44         printf ("Updated strings: s1= %s, s2= %s...\n", s1, s2);
 *        45
 *      (gdb) break main
 *        Breakpoint 1 at 0x80484c8: file x.cpp, line 34.
 *        <= "B MAIN" SETS A BREAKPOINT AT THE VERY BEGINNING OF THE PROGRAM
 *      (gdb) r 123
 *        <= START OVER
 *        Breakpoint 1, main (argc=2, argv=0xbffff3f4) at x.cpp:34
 *        34         if (argc != 2)
 *        (gdb) n
 *        41         printf ("Original strings: s1= %s, s2= %s...\n", s1, s2);
 *        (gdb) n
 *        Original strings: s1= abc, s2= abc...
 *        42         strcpy (s1, argv[1]);
 *        <= "NEXT" SINGLE-STEPS THROUGH A SOURCE LINE AT A TIME
 *        (gdb) p s1
 *        $1 = 0x8048678 "abc"
 *        (gdb) print argv[1]
 *        $2 = 0xbffff5b0 "123"
 *        <= "PRINT" PRINTS THE CURRENT VALUE/TYPE OF A VARIABLE
 */
#include <stdio.h>
#include <string.h>

int
main (int argc, char *argv[])
{
   static char *s1 = "abc";
   static char s2[] = "abc";

   // Check cmd-line
   if (argc != 2)
   {
     printf ("SAMPLE USAGE: x 123!\n");
     return 1;
   }   

   // Copy cmd-line into static string
   printf ("Original strings: s1= %s, s2= %s...\n", s1, s2);
   strcpy (s1, argv[1]);
   strcpy (s2, argv[1]);
   printf ("Updated strings: s1= %s, s2= %s...\n", s1, s2);

   // Done
   return 0;
}
'Hope that helps .. PSM

Last edited by paulsm4; 05-25-2006 at 02:05 PM.
 
Old 05-26-2006, 08:13 PM   #7
cris123
LQ Newbie
 
Registered: May 2006
Posts: 3

Original Poster
Rep: Reputation: 0
I caught the problem

but still strange..

anyway, thanks for those helps and advices. sample to practice gdb will be very useful to me

here's what i have done

--------------------------

there is a global one-dim array variable double Kappa[10], and their value are all 1 (Kappa[i] = 1.0)

and there is a equation like

a = b / Kappa[i] // i is an index in loop

this made error in running under g++ (although compiling it tells me no problem)

since Kappa[i] are all 1.0, i have changed the equation "a=b/Kappa[i]" to "a=b"

and then.. wow! it runs well!

more weird is now, this code doens't work under VC++ -_-;

so here is my conclusion.. : computer cannot do dividing thing, and i cannot trust computer's computation.

ps. my code is about FDTD.. it's simulation about electric field and magnetic field.
anyone interested? ^^
 
Old 05-26-2006, 08:52 PM   #8
graemef
Senior Member
 
Registered: Nov 2005
Location: Hanoi
Distribution: Fedora 13, Ubuntu 10.04
Posts: 2,379

Rep: Reputation: 148Reputation: 148
Usually computers don't have much trouble dividing. Do you know what the values of b and Kappa[] were immediately prior to the crash. My suspicion is that global Kappa[] is hidden by a local scalar version and thus not properly set up at the point of execution.
 
Old 05-27-2006, 12:36 AM   #9
daihard
Member
 
Registered: Jul 2003
Location: Seattle, WA
Distribution: Kubuntu 14.04 LTS
Posts: 915

Rep: Reputation: 34
Quote:
Originally Posted by graemef
Usually computers don't have much trouble dividing. Do you know what the values of b and Kappa[] were immediately prior to the crash. My suspicion is that global Kappa[] is hidden by a local scalar version and thus not properly set up at the point of execution.
I would also make sure all elements of Kappa are properly initialized. How did you do the initialization?
 
  


Reply

Tags
cheat, gdb, sheet


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Quake 3 run on RH9 , but no run on FC4 roy leong Linux - Games 1 01-27-2006 10:59 AM
Cannot get NVIDIA-Linux-x86_64-1.0-6629-pkg2.run to run properly doctorwebbox Linux - Hardware 0 02-06-2005 06:18 AM
Not able to run audio Cds (not MP3) and run VCDS.. satish427 Linux - Newbie 4 09-24-2004 11:27 PM
Trying to run photoshop in wine. Install, but wont run. bruno buys Linux - Software 14 07-15-2004 04:30 PM
Java applets run fine in Konqueror, but won't run in MS IE. OAnimal Linux - Software 7 12-04-2002 06:32 AM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 11:32 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration