A error about "Address 0x0 is not stack'd, malloc'd or (recently) free'd" in c program under linux environment

[Edit1:]

For the seqName, I declare it as a global parameter at the beginning of the file as

char seqName[20];

[Edit2:]

Aren't those number of passing to the program during the actual execution? I got the following message just by using the valgrind tool. The command I input is:

jl@ubuntu:~/work/dsr_analysis$ valgrind --tool=memcheck --leak-check=yes ./test

[Edit3:]

Sorry, since I am a new user of Valgrind, when I use it, I only typing the command in Edit2.

However, my program dose have some command-line parameters.

Therefore, I think I'd better to debug my program by the new command:

valgrind --tool=memcheck --leak-check=yes ./test foreman.cif 352 288

There is a piece of my program:

height = atoi(argv[3]);

width = atoi(argv[2]);

sprintf(seqName,"%s", argv[1]);

// strcpy(seqName, argv[1]);

After compiling it, a exe file test is generated, then I use Valgrind to check it. Then I got the following message, however I cannot understand what it tends to tell me. Can anyone provide some kind help, Thanks.

jl@ubuntu:~/work/dsr_analysis$ valgrind --tool=memcheck --leak-check=yes ./test

==28940== Memcheck, a memory error detector

==28940== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.

==28940== Using Valgrind-3.6.0.SVN-Debian and LibVEX;

rerun with -h for copyright info

==28940== Command: ./test

==28940==

==28940== Invalid read of size 1

==28940== at 0x40260CA: strcpy (mc_replace_strmem.c:311)

==28940== by 0x804A5C6: main (me_search.c:1428)

开发者_高级运维

==28940== Address 0x0 is not stack'd, malloc'd or (recently) free'd

==28940==

==28940==

==28940== Process terminating with default action of signal 11 (SIGSEGV)

==28940== Access not within mapped region at address 0x0

==28940== at 0x40260CA: strcpy (mc_replace_strmem.c:311)

==28940== by 0x804A5C6: main (me_search.c:1428)

==28940== If you believe this happened as a result of a stack

==28940== overflow in your program's main thread (unlikely but

==28940== possible), you can try to increase the size of the

==28940== main thread stack using the --main-stacksize= flag.

==28940== The main thread stack size used in this run was 8388608.

==28940==

==28940== HEAP SUMMARY:

==28940== in use at exit: 0 bytes in 0 blocks

==28940== total heap usage: 0 allocs, 0 frees, 0 bytes allocated

==28940==

==28940== All heap blocks were freed -- no leaks are possible

==28940==

==28940== For counts of detected and suppressed errors, rerun with: -v

==28940== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 13 from 8)1 contexts (suppressed: 13 from 8)

1 contexts (suppressed: 13 from 8)

You really haven't posted clear enough code to be sure, but if you call your executable with no command-line parameters, then argv[1] will contain a NULL pointer, and argv[2], argv[3] etc. will contain undefined values.

Edit: You need to provide the program with parameters on the valgrind command line (I guess - I don't use valgrind myself). Something like:

valgrind ... ./test foo bar zod

And BTW, calling an executable test is a bad idea on Linux/Unix as it is very easy to get confused with the shell built-in of the same name

There are two things you should check:

1) Make sure that you are being passed the correct number of parameters by checking the value of argc.

2) Make sure that you have used malloc() to allocate enough space in seqName before attempting the strcpy().

I think the point is this: sprintf(seqName,"%s", argv[1])

And what you actually want is sprintf((strcat(seqName,"%s"), argv[1]) judging your code.

What it tries to do here is pass the value of the expression "%s" to be interpreted in the format. That value is specifically a char pointer to a '%' in static memory with a 's' next to it, and then a '\0'.

Edit, oh wait, nevermind, I see it's sprintf, not printf. Then it's probably the argcount

Edit2: Also, is seqName properly initialized and allocated?

Do you check actual number of arguments passed to your program? (argc)

If your program gets less than 3 arguments, and you try to acess argv[1..3] - you'll get segmentation faults, and other unpredictable behaviour.