sprintf leading up to bus error (signal 10)

C

CBFalconer

steve said:
.... snip ...

PS. the google groups -> reply technique has been noted and will
be heeded.

Good. Now you have one more thing to learn - do not top-post.
Your answer belongs after, or possibly intermixed with, the quoted
material to which you reply. Of course you have snipped out the
portions of the quotation that are not relevant to your reply.
Here are some useful links:

http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.greenend.org.uk/rjk/2000/06/14/quoting.html
http://www.i-hate-computers.demon.co.uk/
http://web.ukonline.co.uk/g.mccaughan/g/remarks/uquote.html
 
F

Flash Gordon

steve said:
CBFalconer,

Steve, please post your reply *after* the text you are replying to,
after snipping text that is not relevant to your reply.
When you said I might sort it out myself you were right.

Not based on your posted code. You only *think* you have sorted the
problem, but the code still has *major* problems.
> My problem
was in my allocation of space, which was being done for a pointer to my
data structure and not actually allocating space for the structure
itself.

You've still not got this right.

Do you have a line:
typedef struct {
double lst_T_chan, current_T_chan, lst_t, current_t;
} lst_vals;

static boolean pre_analysis (

What type is boolean? I'll bet it is some kind of integer.
UserInstDef *userInst)
{
boolean status = TRUE;
lst_vals lst_ptr;
boolean allocated = malloc(sizeof(lst_vals));

You probably get a warning on the above line. So replace both of the
above with:
lst_vals *lst_ptr = malloc(sizeof *lst_ptr);

See my previous post in this thread, I'm sure you can find it with Google.
char ptr_test[20];

(void)sprintf(ptr_test,"testing");
send_info_to_scn(ptr_test);

if(!allocated){

Replace this with:
if (!lst_ptr) {
send_error_to_scn("Error allocating memory in pre_analysis");
status = FALSE;
goto END;
}

userInst->seniorData = (void *)&lst_ptr;

When assigning to/from void* pointer variable you don't need to cast to
void*. If the compiler complains then it is probably compiling your code
as C++ rather than C. Replace this line with:
userInst->seniorData = lst_ptr;

You were actually returning a pointer to a *local* variable. Local
variables no longer exist after the function returns (unless they are
declared static).
/*Initialize*/
((lst_vals *)userInst->seniorData)->lst_T_chan = 340.0;
((lst_vals *)userInst->seniorData)->current_T_chan = 340;
((lst_vals *)userInst->seniorData)->lst_t = 0;
((lst_vals *)userInst->seniorData)->current_t = 0;

END:
return status;
}/*pre_analysis()*/

Works.

It might appear to work, but without as a minimum changes such as those
I've outline it is likely to blow up as soon as you try to demonstrate
it to $BIG_CUSTOMER and cause you to fail to get that contract your
company needs to survive.
Thank you all so much for your help.
Next time I'll post the workable code right away.

PS. the google groups -> reply technique has been noted and will be
heeded.

<snip message being replied to>

Well, you are improving on your posting. Now you just have to learn to
post after (or interspersed with) the message you are replying to with
careful trimming of text that is not relevant.
 
D

Default User

Flash said:
Steve, please post your reply after the text you are replying to,
after snipping text that is not relevant to your reply.


Not based on your posted code. You only think you have sorted the
problem, but the code still has major problems.


You've still not got this right.


Do you have a line:
#include <stdlib.h>
somewhere up here? If not, you need to add it.
What type is boolean? I'll bet it is some kind of integer.

You probably get a warning on the above line. So replace both of the
above with: lst_vals *lst_ptr = malloc(sizeof *lst_ptr);


Actually, if boolean is a typedef for int and he doesn't include
<stdlib.h>, he may not get a warning. Not that it is good or anything.
Just two wrongs making for a silent compiler.




Brian
 
S

steve

Steve, please post your reply *after* the text you are replying to,
after snipping text that is not relevant to your reply.

Sorry, there's a learning curve with these forums/newsgroups.
Not based on your posted code. You only *think* you have sorted the
problem, but the code still has *major* problems.


You've still not got this right.


Do you have a line:
#include <stdlib.h>
somewhere up here? If not, you need to add it.

In one of the other posts in this threads I mention that a great deal
of the code is transparent to me in that I can NOT add/remove/alter
portions of it as the application is something very similar to a
c-based model in simulink as was given as an example by someone else in
the thread. Considering I can make it as far as I can in my compiles
etc I would say that it's safe to say that the stdlib.h is included in
the code I can't touch as it is somewhere.

[...]
What type is boolean? I'll bet it is some kind of integer.

yes I should've mentioned this at some point. The majority of the
"shells" of the functions that are provided for me to fill in return
booleans so I'm sure ADS (the circuit simulator where this c-based
model will be used) has taken care of the over head for me.

Boolean is an integer of 1 or 0, which I've found in one of ADS' header
files.

[...]
When assigning to/from void* pointer variable you don't need to cast to
void*. If the compiler complains then it is probably compiling your code
as C++ rather than C. Replace this line with:
userInst->seniorData = lst_ptr;

This I wasn't aware of but will definetly take advantage of.
You were actually returning a pointer to a *local* variable. Local
variables no longer exist after the function returns (unless they are
declared static).

In one of the other posts this has been "resolved" with:

userInst->seniorData = (void *)malloc(sizeof(lst_vals));

of which I am now aware that the (void *) can be removed.
It might appear to work, but without as a minimum changes such as those
I've outline it is likely to blow up as soon as you try to demonstrate
it to $BIG_CUSTOMER and cause you to fail to get that contract your
company needs to survive.

Heh. Thankfully this won't make it to market, so there is no
$BIG_CUSTOMER to tear me to shreds. Just my supervisors...
Well, you are improving on your posting. Now you just have to learn to
post after (or interspersed with) the message you are replying to with
careful trimming of text that is not relevant.

Like this?

Cheers,

Steve
 
F

Flash Gordon

steve said:
Sorry, there's a learning curve with these forums/newsgroups.

Not a problem.
In one of the other posts in this threads I mention that a great deal
of the code is transparent to me in that I can NOT add/remove/alter
portions of it as the application is something very similar to a
c-based model in simulink as was given as an example by someone else in
the thread. Considering I can make it as far as I can in my compiles
etc I would say that it's safe to say that the stdlib.h is included in
the code I can't touch as it is somewhere.

I remember you mentioning that. However the code compiling does *not*
mean that stdlib.h has been included. So unless your package explicitly
states that it is, you should include it yourself. The inclusion does
not have to be at the top of the source file, as long as it is at file
scope and before you use anything from it. It is also safe (I believe)
to include stdlib.h multiple time.
What type is boolean? I'll bet it is some kind of integer.

yes I should've mentioned this at some point. The majority of the
"shells" of the functions that are provided for me to fill in return
booleans so I'm sure ADS (the circuit simulator where this c-based
model will be used) has taken care of the over head for me.

Boolean is an integer of 1 or 0, which I've found in one of ADS' header
files.

[...]

OK. This means that if the compiler did not generate a warning about
assigning the result of malloc to your boolean variable stdlib.h is
*not* included. Not including stdlib.h when you need it is bad and can
lead to things breaking at unexpected moments, such as when you go to
show it working to your boss.
This I wasn't aware of but will definetly take advantage of.


In one of the other posts this has been "resolved" with:

userInst->seniorData = (void *)malloc(sizeof(lst_vals));

of which I am now aware that the (void *) can be removed.

Yes, I saw after I posted.
Heh. Thankfully this won't make it to market, so there is no
$BIG_CUSTOMER to tear me to shreds. Just my supervisors...

Still not nice when it happens, and I *have* seen examples of undefined
behaviour only leading to crashes in front of the customer or the boss.
This happens in real life because they always do things slightly
differently to you and this can cause the undefined behaviour to have a
different effect.
Like this?

Yes, much better thank you.

The only other small point is the attributions at the top are missing.
Your post should have started with something like, "Flash Gordon
wrote:". You should always leave in the attributions for everything that
is still quoted so that people know who wrote what. I've put back the
attribution for what I wrote on this post.
 
O

Old Wolf

steve wrote:
Old said:
I'm not stupid and don't terribly enjoy being moked (If the
boston tea party comment was meant as a joke then I appologize
for having taken it as condescendence).

Sorry for any offence. sprintf() does not allocate any memory,
it writes data to memory that should have been allocated already.
Most standard library functions (other than the 'malloc' family)
do not allocate memory, you should assume this unless there is
documentation to the contrary.
My "solution" of allocating space for 255 characters is an
adequate one because the strings that I'll be dealing
with are significantly shorter than 255 characters.

It would be good to add some checking into your program so that
your sprintf does not overflow the 255 characters, in case you
happen to later run your program with long strings.
If a complete program is required than I'll gladly provide what I can,

What you should do is start with your broken program, and gradually
delete bits that you think are unrelated, and see if the problem
persists. Eventually you will either end up with a small program,
or you will have identified which bit was causing the problem.
(Warning: this technique doesn't always work, because in C sometimes
one broken line can appear to run correctly and have some bad
side-effect in a completely different part of the program).
if(!malloc(sizeof(lst_vals))){
send_error_to_scn("Error allocating memory in pre_analysis");
status = FALSE;
goto END;
}

This calls malloc but does not assign the space to anything...
bound to cause a problem somewhere.
Did you mean to assign it to lst_ptr?
userInst->seniorData = (void *)lst_ptr;

As it stands, this causes undefined behaviour because
lst_ptr has not been assigned a value yet.

This cast on lst_ptr is unnecessary. You can assign any object
pointer to a pointer of type (void *), without casting.
It helps to avoid bugs if you avoid casts unless absolutely necessary.
/*Initialize*/
((lst_vals *)userInst->seniorData)->lst_T_chan = 340.0;

END:
return status;
}/*pre_analysis()*/

Your function doesn't actually use lst_ptr at all: you could
write:
if (!(userInst->seniorData = malloc(sizeof(lst_vals))))
..... error stuff ......

((lst_vals *)userInst->seniorData)->lst_T_chan = 340.0;

BTW I would recommend changing "status = FALSE; goto END;"
to "return FALSE". IMHO it is much clearer to read.
 
C

CBFalconer

steve said:
.... snip ...

Heh. Thankfully this won't make it to market, so there is no
$BIG_CUSTOMER to tear me to shreds. Just my supervisors...


Like this?

Who said newbies are not trainable? You are doing well in the
nettiquette department. One minor point remains - don't trim
attributions for material you quote. There should be something up
there under the 'steve wrote' identifying the author of the portion
with the double ">>" quote marks.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,777
Messages
2,569,604
Members
45,234
Latest member
SkyeWeems

Latest Threads

Top