StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I don't know if perhaps you've changed the names of the arrays in your _my_struct in order to hide the purpose of them (company confidential information, perhaps?), but if that's actually what you've named your arrays, I'm just going to suggest that you name them something that makes sense to you that when someone has to read your code 4 years from now, they'll have some hope of following your initialization loops & understanding what's going on. Same goes for your loop variable <code>iG</code>.</p> <p>My next comment/question is, why are you firing off a thread to initialize this structure that's on the stack of the main thread? Which thread is going to be using this structure once it's initialized? Or are you going to make other threads that will use it? Do you have any mechanism (mutex? semaphore?) to ensure that the other threads won't start using the data until your initialization thread is done initializing it? Which sort of begs the question, why the heck are you bothering to fire off a separate thread to initialize it in the first place; you could just initialize it by calling populate_data() straight from main() and not even have to worry about synchronization because you wouldn't even be starting up any other threads until after it's done being initialized. If you're running on a multicore machine, you might get some small benefit from firing off that separate thread to do the initialization while main() goes on & does other stuff, but from the size of your struct (not tiny, but not huge either) it seems like that benefit would be very miniscule. And if you're running on a single core, you'll get no concurrency benefit at all; you'd just be wasting time firing off another thread to do it due to the context switching overhead; in a unicore environment you'd be better off just calling populate_data() directly from main().</p> <p>Next comment is, your _my_struct is not huge, so it's not going to blow your stack by itself. But it ain't tiny either. If your app will always need only one copy of this struct, maybe you should make it a global variable or a file-scope variable, so it doesn't eat up stack space.</p> <p>Finally, to your actual bug............</p> <p>I didn't bother to try to decipher your cryptic looping code, but valgrind is telling me that you have some conditions that depend on uninitialized locations:</p> <pre><code>~/test/so$ valgrind a.out ==27663== Memcheck, a memory error detector ==27663== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==27663== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==27663== Command: a.out ==27663== ==27663== Thread 2: ==27663== Conditional jump or move depends on uninitialised value(s) ==27663== at 0x8048577: populate_data (so2.c:34) ==27663== by 0x593851: start_thread (in /lib/libpthread-2.5.so) ==27663== by 0x4BDA8D: clone (in /lib/libc-2.5.so) ==27663== ==27663== Conditional jump or move depends on uninitialised value(s) ==27663== at 0x804868A: populate_data (so2.c:40) ==27663== by 0x593851: start_thread (in /lib/libpthread-2.5.so) ==27663== by 0x4BDA8D: clone (in /lib/libc-2.5.so) </code></pre> <p>My so2.c line 34 corresponds with line 9 in your code posting above. My so2.c line 40 corresponds with line 15 in your code posting above.</p> <p>If I add the following at the top of populate_data(), these valgrind errors disappear:</p> <pre><code>memset(arg,0,sizeof(_my_struct_t)); </code></pre> <p>(I modified your struct definition as follows:)</p> <pre><code>typedef struct _my_struct { int pArr[21]; ......... } _my_struct_t; </code></pre> <p>Now just because adding the memset() call makes the errors disappear doesn't necessarily mean that your loop logic is correct, it just means that now those locations are considered "initialized" by valgrind. If having all-zeros in those locations when your initialization loops begin is what your logic needs, then that should fix it. But you need to verify for yourself that such really is the proper solution.</p> <p>BTW... someone suggested using calloc() to get a zeroed-out allocation (rather than using dirty stack space)... that would work too, but if you want populate_data() to be foolproof, you'll zero the memory in it and not in the caller, since (assuming you like your initialization logic as it is), populate_data() is the thing that depends on it being zeroed out, main() shouldn't have to care whether it is or not. Not a biggie either way.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload