From: Sonya B. <son...@ho...> - 2013-10-08 05:54:50
|
DEar All, I'm receiving the segmentation fault error with the following sode snippet, in Code Blocks configured for Gnu Gcc it throws exception exactly at the "printf(argc)" line, I can't see any malfunctioning thing other than argc. What can be teh error here ? CODE SNIPPET int main( int argc, char **argv ) ..... ..... printf(argc); SlepcInitialize(&argc,&argv,(char*)0,help); myfile= fopen("IN.txt","r"); ERRORS Program received signal SIGSEGV, Segmentation fault. In rand () (C:\Windows\SysWOW64\msvcrt.dll) Debugger finished with status 0 |
From: LRN <lr...@gm...> - 2013-10-08 06:09:11
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08.10.2013 09:54, Sonya Blade wrote: > DEar All, > > I'm receiving the segmentation fault error with the following sode snippet, in Code Blocks > configured for Gnu Gcc it throws exception exactly at the "printf(argc)" line, > I can't see any malfunctioning thing other than argc. What can be teh error here ? > > > CODE SNIPPET > > int main( int argc, char **argv ) > ..... > ..... > printf(argc); > SlepcInitialize(&argc,&argv,(char*)0,help); > myfile= fopen("IN.txt","r"); > > > > ERRORS > Program received signal SIGSEGV, Segmentation fault. > In rand () (C:\Windows\SysWOW64\msvcrt.dll) > Debugger finished with status 0 printf() takes a format string (char *) and a variable (possibly empty) list of arguments for that format string. You are giving it an integer. - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJSU6F7AAoJEOs4Jb6SI2CwpQQH/05jN98ZQ+ttT7AZpN8rew59 HCyzc9rSs9IS/8xFUl+8RveTtlRbj1O2Bg/7lpFJ9a1ZoNar4e7s8WqT1sNOkSUO +2NasBqBNNyl5R/meZ2itV0ePMSvF5vAKcARarQwaJNNcACPYH3pndvRrryAaQb7 j4X27aed/vM/FUJhwUq485xiXejMEuxa8pZnZuIsALDbzRsftIquo3l0OJkyWhW6 WpsOAhs0CoVGkgaTCwiLrAVLYKayTGyc7tHXDueuN50jZ7mDh0AmkXXByyTAo3Ad WxBOSJmCXC7k84UgptSV13MOfUhu7aNPlFJlfXMt45RoOZwUFR7qJ/adPFDfWc0= =d3lC -----END PGP SIGNATURE----- |
From: Sonya B. <son...@ho...> - 2013-10-08 10:29:35
|
>printf() takes a format string (char *) and a variable (possibly empty) >list of arguments for that format string. > >You are giving it an integer. OK I've tried to manipulate it directly from code instead of relying to the console argument. Due to that I altered code a bit, this time it's a SlepcInitilize function that thorws the exception, any hint on that ? CODE SNIPPET int main( int argc, char **argv ) ..... .... argc =3; argv ="-eps_nev 4 -eps_smallest"; SlepcInitialize(&argc,&argv,(char*)0,help); ERROR OUTPUT FROM DEBUGGER t D:\TEST_FOLDER_asus\PROJECTS\CBFortran\Slepc_C\Slepc_Subspace\main.c:24 Program received signal SIGSEGV, Segmentation fault. In strncat () (C:\Windows\SysWOW64\msvcrt.dll) 217 /cygdrive/d/TEST_FOLDER_asus/petsc-3.4.2/src/sys/objects/options.c: No such file or directory. #2 0x0065f761 in PetscSetProgramName (name=0x7370652d <Address 0x7370652d out of bounds>) at /cygdrive/d/TEST_FOLDER_asus/petsc-3.4.2/src/sys/objects/options.c:217 Debugger finished with status 0 |
From: LRN <lr...@gm...> - 2013-10-08 11:02:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08.10.2013 14:29, Sonya Blade wrote: >> printf() takes a format string (char *) and a variable (possibly empty) >> list of arguments for that format string. >> >> You are giving it an integer. > > OK I've tried to manipulate it directly from code instead of relying to the > console argument. Due to that I altered code a bit, this time it's a SlepcInitilize > function that thorws the exception, any hint on that ? > > > CODE SNIPPET > > int main( int argc, char **argv ) > ..... > .... > > argc =3; > argv ="-eps_nev 4 -eps_smallest"; > > SlepcInitialize(&argc,&argv,(char*)0,help); My guess is that SlepcInitialize[1] can partially consume command line arguments that your program was invoked with, which is why it takes a pointer to argc and a pointer to argv. It's probably OK to give it &argc, but with argv you're doing something really crazy. Argv is a pointer to an array of 'char*' (that is, 'char **'). But you are replacing it with a plain 'char *'. Try compiling with - -Wall, you will likely see gcc complaining about it. I can't tell you how to give it your own argvs exactly, because it depends on what SlepcInitialize() is doing with them (it does not seem to be documented anywhere, or at least i can't google it up). Anyway, most of your problems seem to be stemming from your poor grasp of C, not from MinGW being broken. Also, from your gdb output it looks like slepc comes with debug info, but gdb can't find its source code. I would suggest getting the source code and using gdb 'set substitute-path'[2] command to hook it up so that you can see inside of SlepcInitialize(). [1] http://www.grycap.upv.es/slepc/documentation/current/docs/manualpages/sys/SlepcInitialize.html [2] https://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html#set%20substitute-path - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJSU+YnAAoJEOs4Jb6SI2CwX2kH/1WWloCE+OeAvrUKsaxtV/A/ w0posvHJbXhJwlRbREH5rS5ihXLf6Tk9q2DuCJsPGBHSW5gv080GGgJLl/cuDpeo MiN0gzeCwm4noi0+95fWJHU0OILQE/40w+fqtPkpTUvlpFW4n4tsZWG6z9bpgJx8 5bZ7I3m/EwOm2PRO88zXt98GX0uuQ1NUrcPs5ZGHco/L9nSe1mF55xnTbuB9RlRc tPBhRNePPCbH04KaQ+cJRmpTDCw07GlsUmw9nHSnMk3CctYLh5myybJ++5I2xum5 PfAq7/BWnM2aCiEy6wDvZ+Zx6VjcLS7S8pMGX4N4pME2euVOrSK0qBZfaF/P5Ac= =zBMV -----END PGP SIGNATURE----- |
From: Earnie B. <ea...@us...> - 2013-10-08 11:31:04
|
On Tue, Oct 8, 2013 at 7:01 AM, LRN wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08.10.2013 14:29, Sonya Blade wrote: >>> printf() takes a format string (char *) and a variable (possibly empty) >>> list of arguments for that format string. >>> >>> You are giving it an integer. >> >> OK I've tried to manipulate it directly from code instead of relying to the >> console argument. Due to that I altered code a bit, this time it's a SlepcInitilize >> function that thorws the exception, any hint on that ? >> >> >> CODE SNIPPET >> >> int main( int argc, char **argv ) >> ..... >> .... >> >> argc =3; >> argv ="-eps_nev 4 -eps_smallest"; >> >> SlepcInitialize(&argc,&argv,(char*)0,help); > > My guess is that SlepcInitialize[1] can partially consume command line > arguments that your program was invoked with, which is why it takes a > pointer to argc and a pointer to argv. > Based on the documentation you pointed to > It's probably OK to give it &argc, but with argv you're doing something > really crazy. Argv is a pointer to an array of 'char*' (that is, 'char > **'). But you are replacing it with a plain 'char *'. Try compiling with > - -Wall, you will likely see gcc complaining about it. > The SlepcInitialize wants a pointer the the pointer pointer so &argv should be correct. The OP doesn't show us the definition of help so that may be an issue and it should be NULL for the 3rd argument not (char *)0. > Anyway, most of your problems seem to be stemming from your poor grasp > of C, not from MinGW being broken. > Yea, we all have to learn somewhere and sometimes we just simply forget what we've learned before. > Also, from your gdb output it looks like slepc comes with debug info, > but gdb can't find its source code. I would suggest getting the source > code and using gdb 'set substitute-path'[2] command to hook it up so > that you can see inside of SlepcInitialize(). > > [1] > http://www.grycap.upv.es/slepc/documentation/current/docs/manualpages/sys/SlepcInitialize.html > [2] > https://sourceware.org/gdb/onlinedocs/gdb/Source-Path.html#set%20substitute-path Thanks for the links; they help me understand what SlepcInitialize was. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Sonya B. <son...@ho...> - 2013-10-08 18:52:05
|
>The SlepcInitialize wants a pointer the the pointer pointer so &argv >should be correct. The OP doesn't show us the definition of help so >that may be an issue and it should be NULL for the 3rd argument not >(char *)0. Having 3rd or 4th argument set to NULL doesn't have any effect on elimination of the segfault. One thing has drawn my attention from the error code, originating library for segfault resides in "c:/Windows/SysWow64/msvcrt.dll". Is it expected sequence of reference to libray ? Because I've compiled everything with mingw32(by cygwin) and I would expect "C:/windows/system32/msvcrt.dll " instead of "c:/Windows/SysWow64/msvcrt.dll" ? Is it normal behaviour? At D:\TEST_FOLDER_asus\PROJECTS\CBFortran\Slepc_C\Slepc_Subspace\main.c:24 Program received signal SIGSEGV, Segmentation fault. In strncat () (C:\Windows\SysWOW64\msvcrt.dll) 217 /cygdrive/d/TEST_FOLDER_asus/petsc-3.4.2/src/sys/objects/options.c: No such file or directory. #2 0x0065f761 in PetscSetProgramName (name=0x7370652d <Address 0x7370652d out of bounds>) at /cygdrive/d/TEST_FOLDER_asus/petsc-3.4.2/src/sys/objects/options.c:217 Debugger finished with status 0 |
From: Joaquin M. <jme...@ve...> - 2013-10-14 17:32:04
|
On 10/8/13 11:51 AM, Sonya Blade wrote: > One thing has drawn my attention from the error code, originating library for segfault > resides in "c:/Windows/SysWow64/msvcrt.dll". Is it expected sequence of reference to libray ? > Because I've compiled everything with mingw32(by cygwin) and I would expect "C:/windows/system32/msvcrt.dll " > instead of "c:/Windows/SysWow64/msvcrt.dll" ? Is it normal behaviour? >From my understanding, the %windir%\System32 is reserved for 64-bit applications. This is because most DLL file names were not changed when 64-bit versions of the DLLs were created. The 32-bit versions of the DLLs are stored n the WOW64 directory. Whenever a 32-bit application attempts to access %windir%\System32, the access is redirected to %windir%\SysWOW64. (Gleamed this knowledge from Puppet folks, which cite this MSDN page: http://msdn.microsoft.com/en-us/library/aa384187%28v=vs.85%29.aspx) Some Windows, may have a %WinDir%\Sysnative alias that points to the appropriate platform's target environment (64bit or 32bit), despite running from 32-bit application. Win2003 needs a patch to make this work: http://support.microsoft.com/kb/942589/en-us. |
From: Nathan R. <zer...@ho...> - 2013-10-08 19:16:22
|
>>The SlepcInitialize wants a pointer the the pointer pointer so &argv >>should be correct. The OP doesn't show us the definition of help so >>that may be an issue and it should be NULL for the 3rd argument not >>(char *)0. > > Having 3rd or 4th argument set to NULL doesn't have any effect on > elimination of the segfault. In your first code snippet, you were using printf() incorrectly. In your second code snippet, you fixed that problem but introduced a new one by assining a char* to a char**, which is nonsense: argv ="-eps_nev 4 -eps_smallest"; (If you don't understand why that is nonsense, you should figure that out before you try to write more code. I'd recommend reading a book on C programming, and asking questions on StackOverflow about things you still don't understand.) Have you tried simply passing in the addresses of argc and argv to SlepcInitialize, which it what it seems to expect? As in: int main( int argc, char **argv ) { // don't touch argc or argv here .... SlepcInitialize(&argc,&argv,(char*)0,help); ... } > One thing has drawn my attention from the error code, originating library for segfault > resides in "c:/Windows/SysWow64/msvcrt.dll". Is it expected sequence of reference to libray ? > Because I've compiled everything with mingw32(by cygwin) and I would expect "C:/windows/system32/msvcrt.dll " > instead of "c:/Windows/SysWow64/msvcrt.dll" ? Is it normal behaviour? Yes. Very confusingly, on 64-bit Windows systems, the 32-bit libraries are in SysWow64 and the 64-bit libraries are in system32. Regards, Nate |
From: Keith M. <kei...@us...> - 2013-10-08 20:19:46
|
On 08/10/13 20:16, Nathan Ridge wrote: >>> The SlepcInitialize wants a pointer the the pointer pointer so &argv >>> should be correct. The OP doesn't show us the definition of help so >>> that may be an issue and it should be NULL for the 3rd argument not >>> (char *)0. >> >> Having 3rd or 4th argument set to NULL doesn't have any effect on >> elimination of the segfault. (char *)0 is equivalent to NULL; either should work identically. This is not the cause of your segfault. > In your first code snippet, you were using printf() incorrectly. And in a manner which would be very likely to induce a segfault, because you passed the value of argc, (a relatively small integer), to a function which would interpret it as a pointer, to (probably) inaccessible memory. > In your second code snippet, you fixed that problem but introduced a > new one by assining a char* to a char**, which is nonsense: > > argv ="-eps_nev 4 -eps_smallest"; Like Nate says: nonsense; also likely the cause of your next segfault, because you've now passed this garbage to a function which is expecting an array of pointers, to exactly argc strings followed by a terminating NULL pointer, and in trying to interpret it as such, it has again tried to access inaccessible memory. > (If you don't understand why that is nonsense, you should figure that > out before you try to write more code. I'd recommend reading a book > on C programming, ... Either that, or seek one of the abundant tutorials on the web; Steve Summit's is usually reckoned to be quite good, even if rather old. > ... and asking questions on StackOverflow about things you still > don't understand.) This is also good advice. -- Regards, Keith. |
From: K. F. <kfr...@gm...> - 2013-10-08 22:12:13
|
Hello Microsoftians! On Tue, Oct 8, 2013 at 3:16 PM, Nathan Ridge <> wrote: > ... > Yes. Very confusingly, on 64-bit Windows systems, the 32-bit libraries are in SysWow64 > and the 64-bit libraries are in system32. > ... Yay! Microsoft! I just have to laugh. Because if I don't laugh ... I'll cry ... K. Frank |
From: Joaquin M. <jme...@ve...> - 2013-10-14 17:36:35
|
On 10/8/13 12:16 PM, Nathan Ridge wrote: >> One thing has drawn my attention from the error code, originating library for segfault >> resides in "c:/Windows/SysWow64/msvcrt.dll". Is it expected sequence of reference to libray ? >> Because I've compiled everything with mingw32(by cygwin) and I would expect "C:/windows/system32/msvcrt.dll " >> instead of "c:/Windows/SysWow64/msvcrt.dll" ? Is it normal behaviour? > Yes. Very confusingly, on 64-bit Windows systems, the 32-bit libraries are in SysWow64 > and the 64-bit libraries are in system32. > 32-bit programs see 32-bit libraries in both SysWow64 and system32, and 64-bit programs see 64-bit libraries in system32. 32-bit programs can see 64-bit libraries in Sysnative. I mention this in the odd chance that any 32-bit tool creating/compiling/working needs access to 64-bit libraries. |