You are correct, a seg fault occurs when attempting to access memory that the application hasn't allocated.
I would try using gdb to track down the problem. Compile the app using the "-g" attribute, for example, "g++ -g -o myapp myapp.cpp", and then run the app in gdb, "gdb myapp". Once in gdb, you can type "help" to get a list of commands. I would start by just typing "run" first, and gdb should show the code where the seg fault occured. You can also follow the "run" command with any arguements for the app, they will be passed to the app. After the segfault occurs, you can type "backtrace" to see what calls were made to get into that function. Also, note that applications may not run the same in gdb as they normally do without compiling using the "-g" attribute. Sometimes a program that normally produces errors will run without errors under gdb, or gdb may produce more errors than normal. This is due to the extra debugging code that gdb adds. -Mike -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- "Bishop, Peter G" <[EMAIL PROTECTED]> Sent by: Linux on 390 Port <[email protected]> 03/22/2006 07:51 PM Please respond to Linux on 390 Port <[email protected]> To [email protected] cc Subject dumb porting question about seg faults Hi, we have a C++ application for a client and we're trying to upgrade to the latest version supplied by the vendor. They say it installs beautifully on Lintel or Windoze, but when we run the install script on zLinux it seg faults. They aren't really a zSeries-aware vendor, but have supplied the source for us to build our own zSeries version. They claim no changes have been made since the last version installed successfully that might cause this behaviour, something I'm prepared to admit for now as they have a working non-mainframe version in the public arena. As near as I can tell, this "strace" output seems to be the show the error happens: ---start extract of output from strace of the install process ...snipped lots of earlier stuff... write(1, "rm -f sdb/australia/aust*\n", 26) = 26 rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT TERM XCPU XFSZ], NULL, 8) = 0 fork() = 10057 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 wait4(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 10057 --- SIGCHLD (Child exited) --- sigreturn() = ? (mask now []) write(1, "bin/buildsdb sdb/australia/aust "..., 243) = 243 rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT TERM XCPU XFSZ], NULL, 8) = 0 fork() = 10058 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 wait4(-1, [WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV], 0, NULL) = 10058 --- SIGCHLD (Child exited) --- sigreturn() = ? (mask now []) write(2, "make: ", 6make: ) = 6 write(2, "*** [build_au_sdb] Segmentation "..., 37*** [build_au_sdb] Segmentation fault) = 37 write(2, "\n", 1 ) = 1 stat64("build_au_sdb", 0x7fffd818) = -1 ENOENT (No such file or directory) rt_sigprocmask(SIG_BLOCK, [HUP INT QUIT TERM XCPU XFSZ], NULL, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 chdir("/qlbase/output/v2.2n/ql") = 0 munmap(0x40015000, 4096) = 0 _exit(2) = ? sydvs001:/qlbase/output/v2.2n/ql # ---end extract of output from strace of the install process I admit to not knowing much about C++. From the above it seems that a couple of child processes exited, the last one of which is logged as the seg fault "problem child". I thought seg faults are kind of like S0C4s in "traditional" MVS abend terms, i.e. you're treading somewhere you shouldn't. I've bumped up the VM size of this guest to its max of 2G (it's a 31-bit guest) and still the seg fault happens. Can anyone suggest a reason why a seg fault might happen on one platform but not another? Please excuse my ignorance if I've phrased the question badly. cheers Peter Peter Bishop Mainframe IT Outsourcing Service Delivery EDS Asia-Pacific phone: +61 2 9012 5147 + mailto:[EMAIL PROTECTED] ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
