Can someone interpret this for me?

Question

Program received signal SIGSEGV, Segmentation fault.
memcpy ()
    at ../sysdeps/x86_64/multiarch/../multiarch/memmove-vec-unaligned-erms.S:143
143 ../sysdeps/x86_64/multiarch/../multiarch/memmove-vec-unaligned-erms.S: No such file or directory.
(gdb) bt
#0  memcpy ()
    at ../sysdeps/x86_64/multiarch/../multiarch/memmove-vec-unaligned-erms.S:143
#1  0x00007ffff764aa2e in __GI__IO_default_xsputn (f=0x7fffffffcf30, 
    data=<optimized out>, n=30) at genops.c:438
#2  0x00007ffff761c59c in _IO_vfprintf_internal (
    s=s@entry=0x7fffffffcf30, format=<optimized out>, 
    format@entry=0x55555555773f "%s/%s", ap=ap@entry=0x7fffffffd058)
    at vfprintf.c:1637
#3  0x00007ffff763e61b in __IO_vsprintf (
    string=0x3930313938393339 <error: Cannot access memory at address 0x3930313938393339>, format=0x55555555773f "%s/%s", 
    args=args@entry=0x7fffffffd058) at iovsprintf.c:42
#4  0x00007ffff7623717 in __sprintf (s=<optimized out>, 
    format=<optimized out>) at sprintf.c:32
#5  0x000055555555680e in take_action (
    hash=0x7fffffffd4d0 "4ef3065e42d1ba6d821e734b2957b264", 
    index=0x7fffffffd36c, filnamE=0x7fffffffd5d0 "fs", 
    time_s=0x7fffffffd4a0 "1493989109") at file_sync.c:652
#6  0x0000555555556f25 in run_client (port_no=10009) at file_sync.c:821
#7  0x00005555555571df in main (argc=3, argv=0x7fffffffdef8)
    at file_sync.c:923

The code I'm getting this for is:

    char *fnam;
    int nn = sprintf(fnam,"%s/%s",cwd,filnam);
    fnam[nn] = '\0';

where cwd is a string with value : "/home/username/dir1/dir2/di3" filnam has value : fs

I know these are the values because I've printed them out.

Can someone interpret this error for me? I cant seem to figure this out. Please help me with this! Thanks!

EDIT:

Okay here's the declarations as asked for:

char cwd[256];
getcwd(cwd, sizeof(cwd));
**// getting cwd here**

DIR *directory = NULL;
pdir = opendir(cwd);

if(directory ==  NULL){printf("\nDirectory bad!!\n");exit(1);}  
char * filnam;
struct dirent *uppp = NULL;
while( uppp = readdir(directory) ) 
{
    if(uppp == NULL){printf("\nproblemo. \n"); exit(1);}
    filnam = uppp->d_name;
    if(filnam[0] == '.') { continue; }
**// this is where I'm getting filename**



}

There's a clear error at the top. Did you look up what a segmentation is? — Carcigenicate, May 05 '17 at 13:04
Its not a segmentation fault, I used that same sized array for much larger strings, it fails for that file. That is why this is confusing — SEsuks, May 05 '17 at 13:05
`Program received signal SIGSEGV, Segmentation fault`. It would appear it is a segfault. — Carcigenicate, May 05 '17 at 13:06
Could you post `cdw` and `filenam` declaration? Or, event best, an [MCVE](http://stackoverflow.com/help/mcve) — LPs, May 05 '17 at 13:07
What I'm trying to say it, it says that but there be some deeper meaning in the error I cant figure out because its handling much larger filenames fine — SEsuks, May 05 '17 at 13:07
But if you are not allocating `fnam[]` correctly, and overrunning the memory buffer, behaviour is undefined. It may work at some points, and then not at others. — Paul Bentley, May 05 '17 at 13:09
You don't need to `null` terminate a string when using `sprintf()` unless the length exceeds available space, and in that case it's clearly wrong to do so. Use `snprintf()` to avoid a buffer overflow, and in turn you can check if the `sprint()`ed string fits into the target array. — Iharob Al Asimi, May 05 '17 at 13:12
The key to your problem is here `string=0x3930313938393339 ` To me that looks more like ASCII than an address :-o — cleblanc, May 05 '17 at 13:13
@LPs check my edit. Also does that mean snprintf() automatically nulls the string? — SEsuks, May 05 '17 at 13:14
From [the man](https://linux.die.net/man/3/snprintf): _The functions snprintf() and vsnprintf() write at most size bytes (including the terminating null byte ('\0')) to str._ — LPs, May 05 '17 at 13:15
I saw an answer here before, was that wrong? Why did it get deleted? — SEsuks, May 05 '17 at 13:15
`if(uppp == NULL){printf("\nproblemo. \n"); exit(1);}` is extremely unpleasant to read and, not necessary because `uppp` is not going to be `NULL` inside the loop because of the loop control. It seems to me that you are double checking *just to be sure*, and that's a terrible thing, it's an indicator that you don't know what your doing. — Iharob Al Asimi, May 05 '17 at 13:16
Please post a [MCVE] <<< click here and read the explanation. The problem is in the code you didn't show us. — Jabberwocky, May 05 '17 at 13:19
I miss the definition of `fnam`, to which `sprintf` is going to write — Stephan Lechner, May 05 '17 at 13:19
The answer was deleted because one comment said it should be a comment and the other comment written by you claimed it was wrong. — JeremyP, May 05 '17 at 13:21
@IharobAlAsimi It returns NULL when it reaches the end of the directory or some error occurs, are you asking me why I did it a while loop? Also if it looks unpleasant or not is not part of my question — SEsuks, May 05 '17 at 13:21
@SEsuks The code will never enter the `while` body if `uppp` is `NULL`, if you can't see that I recommend you try to understand basics better. It looks unpleasant so don't get used to writing such ugly code because it says more than you thing about the quality of your code. I am not trying to belittle you or your code, it's just my opinion and it's something I would like you to take into account in the future, so that you become a better programmer. — Iharob Al Asimi, May 05 '17 at 13:24
@IharobAlAsimi `uppp` is not null. The while condition is an assignment. — JeremyP, May 05 '17 at 13:26
@JeremyP Yes, and the assignment result will be evaluated, if it's `NULL` then it will be "*false*", that's why I prefer `while ((uppp = readdir(directory)) != NULL)` which is more clear. In fact, gcc at least warns about this saying *assignment used as truth value should have extra parentheses* or something like that. — Iharob Al Asimi, May 05 '17 at 13:26
@IharobAlAsimi I prefer your style too but that does not mean there is a bug here. `readdir` only returns `NULL` when you get to the end of the directory. — JeremyP, May 05 '17 at 13:29
I dont get why I'm getting heat for something not related to my question. I thought SO is about programming questions, not "bashing novice programmers to show your zeal" kind of site — SEsuks, May 05 '17 at 13:37
@SEsuks Much of what I know I learned because someone pointed out that something that I did was bad practice, or not good logic. So don't be defensive, there is no bashing involved. It's just that the real problem answered [here](http://stackoverflow.com/a/43806093/1983495) and the things that I pointed out are related, because they both indicate the same thing. If you ever want to become a great programmer you need to be ready to polish every single thing that you do, that is considered bad practice. In your case, it's just clearly a lack of understanding a very basic thing about the language — Iharob Al Asimi, May 05 '17 at 13:45
You are getting heat because your question - as originally posed - omitted the necessary information to answer it. Fifth comment down LPs posted the link to making an MCVE. "MCVE" stands for minimal complete verifiable example. If you had followed its advice, you would have had an answer straight away with none of the aggravation that has gone on since. We don't ask gfor MCVE's to beat you up, we ask for them because they make it easier to answer the question which help you and it helps us. Treat this as a learning experience for next time. — JeremyP, May 05 '17 at 14:20
I can understand that part (MCVE) and it was a mistake, I'm no expert and I did comply to y'alls requests and am thankful for your help. I was not talking about the code requests at all, that is fine and necessary, in fact I appreciate anyone correcting me in helping them understand, to answer the question better. In fact I'll duly provide any more info when needed. I was talking about why __after__ my giving all the necessary information does someone waltz about something not related to the question (the (while, readdir, if, NULL) thing), that was something not related to the question at all. — SEsuks, May 05 '17 at 15:13

score 7 · Answer 1 · answered May 05 '17 at 13:21

7

The problem is here:

char *fnam;
int nn = sprintf(fnam,"%s/%s",cwd,filnam);
fnam[nn] = '\0';

fnam is not initialized.

Try this:

char fnam[500];
int nn = sprintf(fnam,"%s/%s",cwd,filnam);

// -> remove this, it's not necessary: 
//    fnam[nn] = '\0';

answered May 05 '17 at 13:21

Jabberwocky

48,281
17
65
115

I though so, but OP said that fnam is size 256... we'll see... – LPs May 05 '17 at 13:22
1

@LPs OP has just had a declaration for `fnam` added. Now he has done so, the answer is obvious (it's uninitialised). – JeremyP May 05 '17 at 13:24
1

@LPs the OP just added the offending code to the question. – Jabberwocky May 05 '17 at 13:24
WT............ ;) OP has my DV now... – LPs May 05 '17 at 13:25
1

@SEsuks In the previous answer you wrote: _fnam is size 256. Directly from the terminal: cwd "/home/uuuu/ATLAS/CONFIG/ARCHS" fnam "fs"_... WTx!!!! You are wasting our time – LPs May 05 '17 at 13:27
@SEsuks If you want to be sure that it *really* works, use [*valgrind*](http://valgrind.org), that way you will be very sure that there are no invalid reads or writes (uninitialized memory), nor memory leaks. – Iharob Al Asimi May 05 '17 at 13:29

Can someone interpret this for me?

1 Answers1