473,326 Members | 2,125 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

access of memory beyond allocation, not causing segmentation fault...

Hi Everyone,

I have the following program unit,

#include <stdlib.h>

int main()
{
char *p = (char*)malloc(100);
if(p==NULL)
{
printf("...null...\n");
}
else
{
printf("...success...\n");
printf("1.%d\n",p[10]);
memset(p,0,101);
printf("2.%d\n",p[10]);
free(p);
printf("3.%d\n",p[101]);
}
}

I used gcc on Solaris OS and i get the following output,

1.0
2.0
3.0

Shouldn't the following statements cause a segmentation fault?

printf("3.%d\n",p[101]);
//As i'm referring to p after the memory is deallocated
memset(p,0,101);
//As access to memory is beyond the allocated portion.

Thanks in advance!!!

May 9 '07 #1
23 1673
sa*****@yahoo.co.in wrote:
Hi Everyone,

I have the following program unit,

#include <stdlib.h>

int main()
{
char *p = (char*)malloc(100);
if(p==NULL)
{
printf("...null...\n");
}
else
{
printf("...success...\n");
printf("1.%d\n",p[10]);
memset(p,0,101);
printf("2.%d\n",p[10]);
free(p);
printf("3.%d\n",p[101]);
}
}

I used gcc on Solaris OS and i get the following output,

1.0
2.0
3.0

Shouldn't the following statements cause a segmentation fault?

printf("3.%d\n",p[101]);
//As i'm referring to p after the memory is deallocated
memset(p,0,101);
//As access to memory is beyond the allocated portion.
Nope, you just invoke the demons of undefined behavior.

--
Ian Collins.
May 9 '07 #2

<sa*****@yahoo.co.inwrote in message
news:11********************@u30g2000hsc.googlegrou ps.com...
Hi Everyone,

I have the following program unit,

#include <stdlib.h>

int main()
{
char *p = (char*)malloc(100);
if(p==NULL)
{
printf("...null...\n");
}
else
{
printf("...success...\n");
printf("1.%d\n",p[10]);
memset(p,0,101);
printf("2.%d\n",p[10]);
free(p);
printf("3.%d\n",p[101]);
}
}

I used gcc on Solaris OS and i get the following output,

1.0
2.0
3.0

Shouldn't the following statements cause a segmentation fault?

printf("3.%d\n",p[101]);
//As i'm referring to p after the memory is deallocated
memset(p,0,101);
//As access to memory is beyond the allocated portion.

Thanks in advance!!!
You need to compile with a bounds checking flag. Even then, you are not
guaranteed a segmentation fault because bounds checking doesn't work
perfectly.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

May 9 '07 #3
sa*****@yahoo.co.in wrote:
#include <stdlib.h>

int main()
{
char *p = (char*)malloc(100);
Don't cast malloc(). It is not necessary, should cause no problems with
a good compiler, and can hide errors. Also, unnecessary casts cause
conversion allergies in many programmers.
Shouldn't the following statements cause a segmentation fault?

printf("3.%d\n",p[101]);
//As i'm referring to p after the memory is deallocated
memset(p,0,101);
//As access to memory is beyond the allocated portion.
No. Both cause undefined behaviour. Undefined behaviour is exactly that:
undefined. Nothing is defined about it. It may cause the compiler to
refuse to compile your program, if it can determine in advance that the
UB is guaranteed to be triggered; it may appear to work but actually do
nothing; it may crash with a segfault; it may write to or read from
random memory addresses; it may fire up your email program and send
lurid love-letters to General Musharraf. So don't do that.

Richard
May 9 '07 #4
On May 9, 11:40 am, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
sam_...@yahoo.co.in wrote:
#include <stdlib.h>
int main()
{
char *p = (char*)malloc(100);

Don't cast malloc(). It is not necessary, should cause no problems with
a good compiler, and can hide errors. Also, unnecessary casts cause
conversion allergies in many programmers.
Shouldn't the following statements cause a segmentation fault?
printf("3.%d\n",p[101]);
//As i'm referring to p after the memory is deallocated
memset(p,0,101);
//As access to memory is beyond the allocated portion.

No. Both cause undefined behaviour. Undefined behaviour is exactly that:
undefined. Nothing is defined about it. It may cause the compiler to
refuse to compile your program, if it can determine in advance that the
UB is guaranteed to be triggered; it may appear to work but actually do
nothing; it may crash with a segfault; it may write to or read from
random memory addresses; it may fire up your email program and send
lurid love-letters to General Musharraf. So don't do that.

Richard
But i think the statement, memset(p,0,101); will cause a memory
corruption for sure. And had someone been using that memory, it would
cause a problem for them.
Will memset() ever worry about the allocation or the owner of the
allocation, if i'm correct it would just set the specified memory
bytes with a specific value, isn't it?
May 9 '07 #5
<sa*****@yahoo.co.inwrote in message
news:11**********************@y80g2000hsf.googlegr oups.com...
But i think the statement, memset(p,0,101); will cause a memory
corruption for sure. And had someone been using that memory, it would
cause a problem for them.
Will memset() ever worry about the allocation or the owner of the
allocation, if i'm correct it would just set the specified memory
bytes with a specific value, isn't it?
It depends on your system. A simple computer will just happily overwrite
memory, causing who knows what sort of malfunction. More modern systems
usually have some sort of low-level protection in place, so typically the
result will be a message saying "segmentation fault". However most systems
can't guarantee a segfault on buffer overrun.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

May 9 '07 #6

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:46****************@news.xs4all.nl...
sa*****@yahoo.co.in wrote:
>#include <stdlib.h>

int main()
{
char *p = (char*)malloc(100);

Don't cast malloc(). It is not necessary, should cause no problems with
a good compiler, and can hide errors. Also, unnecessary casts cause
conversion allergies in many programmers.
Very arguable opinion presented as accepted practise and sage advice.
>
>Shouldn't the following statements cause a segmentation fault?

printf("3.%d\n",p[101]);
//As i'm referring to p after the memory is deallocated
memset(p,0,101);
//As access to memory is beyond the allocated portion.

No. Both cause undefined behaviour. Undefined behaviour is exactly that:
undefined. Nothing is defined about it.
No. The C standard defines nothing about it. That doesn't mean nothing is
defined about it elsewhere in the system.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

May 9 '07 #7
Malcolm McLean wrote:
>
"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:46****************@news.xs4all.nl...
>sa*****@yahoo.co.in wrote:
>>#include <stdlib.h>

int main()
{
char *p = (char*)malloc(100);

Don't cast malloc(). It is not necessary, should cause no problems with
a good compiler, and can hide errors. Also, unnecessary casts cause
conversion allergies in many programmers.
Very arguable opinion presented as accepted practise and sage advice.
Let's see:
>It is not necessary
This is true: it's not necessary to cast the result of `malloc` to
assign it to a pointer variable.
>should cause no problems with a good compiler,
This is true: it's legal code and doesn't have nasties in it.
>and can hide errors.
This is true: if you forget to #include <stdlib.h>, and the
compiler doesn't say anything about implicit declaration of
functions, the cast will hide a pointer-to-int conversion,
which might be a convert-gibberish-in-int-register-to-gibberish-
in-pointer-register.
>Also, unnecessary casts cause
conversion allergies in many programmers.
True by exhibition in this newsgroup.

I don't think your comment holds up.
>>Shouldn't the following statements cause a segmentation fault?

printf("3.%d\n",p[101]);
//As i'm referring to p after the memory is deallocated
memset(p,0,101);
//As access to memory is beyond the allocated portion.

No. Both cause undefined behaviour. Undefined behaviour is exactly that:
undefined. Nothing is defined about it.
No. The C standard defines nothing about it.
That's right: that's what "undefined behaviour" means around here.
You've probably not read enough posts to notice.
That doesn't mean nothing is
defined about it elsewhere in the system.
It doesn't mean it is, either. (Accidents of implementation are not
definitions.)

--
"What I don't understand is this ..." Trevor Chaplin, /The Beiderbeck Affair/

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

May 9 '07 #8
sa*****@yahoo.co.in wrote:
On May 9, 11:40 am, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
No. Both cause undefined behaviour. Undefined behaviour is exactly that:
undefined. Nothing is defined about it. It may cause the compiler to
refuse to compile your program, if it can determine in advance that the
UB is guaranteed to be triggered; it may appear to work but actually do
nothing; it may crash with a segfault; it may write to or read from
random memory addresses; it may fire up your email program and send
lurid love-letters to General Musharraf. So don't do that.

But i think the statement, memset(p,0,101); will cause a memory
corruption for sure.
Read the above again. Think about it thoroughly. Then realise that the
answer to your assumption is "this, too, is _undefined_".

Richard
May 9 '07 #9
"Malcolm McLean" <re*******@btinternet.comwrites:
<sa*****@yahoo.co.inwrote in message
news:11**********************@y80g2000hsf.googlegr oups.com...
>But i think the statement, memset(p,0,101); will cause a memory
corruption for sure. And had someone been using that memory, it would
cause a problem for them.
Will memset() ever worry about the allocation or the owner of the
allocation, if i'm correct it would just set the specified memory
bytes with a specific value, isn't it?
It depends on your system. A simple computer will just happily
overwrite memory, causing who knows what sort of malfunction. More
modern systems usually have some sort of low-level protection in
place, so typically the result will be a message saying "segmentation
fault". However most systems can't guarantee a segfault on buffer
overrun.
Such protection typically distinguishes between memory your program
owns and memory it doesn't. It's not able to protect against
overwriting other memory within your own program.

If you call memset(p, 0, 101), where p points to a 100-byte object,
the extra byte that gets clobbered will most likely be either
unallocated memory, or memory that's part of some other object, or
perhaps part of some system-specific bookkeeping data structure
(function return address, heap tracking data, etc.).

The behavior is undefined, so as far as the standard is concerned,
literally anything can happen. But the most likely result of going
*just barely* beyond the bounds of an object is that something within
your program will be corrupted; the symptoms may appear later or not
at all.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
May 9 '07 #10
sa*****@yahoo.co.in wrote:
>
.... snip ...
>
But i think the statement, memset(p,0,101); will cause a memory
corruption for sure. And had someone been using that memory, it
would cause a problem for them.
Will memset() ever worry about the allocation or the owner of the
allocation, if i'm correct it would just set the specified memory
bytes with a specific value, isn't it?
Not necessarily. The previous malloc may well have allocated a
multiple of 8 (or perhaps 16) bytes, which would mean 104 in this
case. The reason is to preserve memory alignment.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

May 9 '07 #11
sa*****@yahoo.co.in wrote:

But i think the statement, memset(p,0,101); will cause a memory
corruption for sure.
There is no defined behavior for undefined behavior.


Brian
May 9 '07 #12

"Chris Dollin" <ch**********@hp.comwrote in message
news:f1**********@murdoch.hpl.hp.com...
Malcolm McLean wrote:
>>
"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:46****************@news.xs4all.nl...
>>sa*****@yahoo.co.in wrote:

#include <stdlib.h>

int main()
{
char *p = (char*)malloc(100);

Don't cast malloc(). It is not necessary, should cause no problems with
a good compiler, and can hide errors. Also, unnecessary casts cause
conversion allergies in many programmers.
Very arguable opinion presented as accepted practise and sage advice.

Let's see:
You and Richard Bos give poweful reasons for losing the cast from malloc().
But for my point to fall, those who retain the cast would have to offer as
"no evidence" position.
As a little intellectual exercise, can you now list some good arguments for
casting malloc()?
>That doesn't mean nothing is
defined about it elsewhere in the system.

It doesn't mean it is, either. (Accidents of implementation are not
definitions.)
This is sounding a bit like medieval philosophy. Accidentally segfaults but
inhering of no substance ...

You shouldn't try to draw too many conclusions about the fact that a
behaviour is undefined by the C standard, except to say that it is not a
correct C program, according to that standard.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

May 9 '07 #13
Malcolm McLean said:

<snip>
As a little intellectual exercise, can you now list some good
arguments for casting malloc()?
No. I tried hard to think of even a single good reason, and failed. P J
Plauger, however, can give one good argument for *P J Plauger* casting
malloc.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
May 9 '07 #14
<sa*****@yahoo.co.inwrote in message
news:11********************@u30g2000hsc.googlegrou ps.com...
Shouldn't the following statements cause a segmentation fault?

printf("3.%d\n",p[101]);
//As i'm referring to p after the memory is deallocated
memset(p,0,101);
//As access to memory is beyond the allocated portion.
They invoke undefined behavior, and the program/implementation is free to do
anything at/after that point _including doing nothing at all_. UB doesn't
mean you'll always get an error, just that your program is no longer
guaranteed to work (but it might, despite the UB -- at least until you
upgrade your compiler/OS, port to a new system, the phase of the moon
changes, etc.).

For _this particular scenario_, the most common result will be that your
program will continue to execute for a while as if you did nothing wrong,
then fail in a completely unrelated part of the code. The second most
common result will be that absolutely nothing will go wrong. The third,
only on particular implementations that do bounds-checking, will be some
sort of run-time error like you seem to expect.

(Most common systems don't do bounds-checking and only catch egregious abuse
of pointers. Most are also lazy about handing memory back to the OS, so you
can still access free()d memory for some period. It's not wise to rely on
these behaviors, however.)

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--
Posted via a free Usenet account from http://www.teranews.com

May 9 '07 #15

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:As*********************@bt.com...
Malcolm McLean said:

<snip>
>As a little intellectual exercise, can you now list some good
arguments for casting malloc()?

No. I tried hard to think of even a single good reason, and failed. P J
Plauger, however, can give one good argument for *P J Plauger* casting
malloc.
I was converted from malloc() casting to non-casting. However, as you say,
some very competent people do retain the cast.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm
May 10 '07 #16
Malcolm McLean wrote:
>
.... snip ...
>
You and Richard Bos give poweful reasons for losing the cast from
malloc(). But for my point to fall, those who retain the cast would
have to offer as "no evidence" position. As a little intellectual
exercise, can you now list some good arguments for casting malloc()?
No. Not in the C language. The only immediately visible effect
will be a) increased clutter and b) omission of some error
messages. ALL casts are suspicious.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
<http://kadaitcha.cx/vista/dogsbreakfast/index.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

May 10 '07 #17
Malcolm McLean said:
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:As*********************@bt.com...
>Malcolm McLean said:

<snip>
>>As a little intellectual exercise, can you now list some good
arguments for casting malloc()?

No. I tried hard to think of even a single good reason, and failed. P
J Plauger, however, can give one good argument for *P J Plauger*
casting malloc.
I was converted from malloc() casting to non-casting. However, as you
say, some very competent people do retain the cast.
I only know of one competent person who retains the cast. P J Plauger.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
May 10 '07 #18
On Wed, 9 May 2007 16:40:24 -0500, "Stephen Sprunk"
<st*****@sprunk.orgwrote:
><sa*****@yahoo.co.inwrote in message
news:11********************@u30g2000hsc.googlegro ups.com...
>Shouldn't the following statements cause a segmentation fault?

printf("3.%d\n",p[101]);
//As i'm referring to p after the memory is deallocated
memset(p,0,101);
//As access to memory is beyond the allocated portion.

They invoke undefined behavior, and the program/implementation is free to do
anything at/after that point _including doing nothing at all_.
qui:
1) se p[101] e' memoria allocata per ragioni di allineamento tutto ok
2) altrimenti se p[101]==0 e si riscrive p[101]=0 tutto ok
3) altrimenti se p[101]!=0 e si scrive p[101]=0 la mia
implementazione di free vede l'errore e esce con il messaggio

ove "tutto ok"=="l'operazione non comporta niente di sbagiato"

in ogni caso nessun UB dipende solo da che cosa vi è scritto in p[101]
e del suo allineamento in memoria; tutto è determinato
>UB doesn't
mean you'll always get an error, just that your program is no longer
guaranteed to work (but it might, despite the UB -- at least until you
upgrade your compiler/OS, port to a new system, the phase of the moon
changes, etc.).

For _this particular scenario_, the most common result will be that your
program will continue to execute for a while as if you did nothing wrong,
then fail in a completely unrelated part of the code.
qui:
1) o non succede niente
2) o free(p) si accorge che qualcosa non va nella struttura di
allocazione ed esce
>The second most
common result will be that absolutely nothing will go wrong. The third,
only on particular implementations that do bounds-checking, will be some
sort of run-time error like you seem to expect.

(Most common systems don't do bounds-checking and only catch egregious abuse
of pointers. Most are also lazy about handing memory back to the OS, so you
can still access free()d memory for some period. It's not wise to rely on
these behaviors, however.)

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
May 10 '07 #19
¬a\/b said:
qui:
1) o non succede niente
2) o free(p) si accorge che qualcosa non va nella struttura di
allocazione ed esce
Are you *trying* to get killfiled?

(Incidentally, you succeeded.)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
May 10 '07 #20
Richard Heathfield wrote:
Malcolm McLean said:
>"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:As*********************@bt.com...
>>Malcolm McLean said:

<snip>

As a little intellectual exercise, can you now list some good
arguments for casting malloc()?

No. I tried hard to think of even a single good reason, and failed.
P J Plauger, however, can give one good argument for *P J Plauger*
casting malloc.
I was converted from malloc() casting to non-casting. However, as you
say, some very competent people do retain the cast.

I only know of one competent person who retains the cast. P J Plauger.
And even he does not advocate to cast the return value from malloc in
general.
To my knowledge, his reason for retaining the cast stems from such an
exceptional situation that it actually *confirms* the rule for not
casting the return value of malloc.

Bart v Ingen Schenau
--
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://www.eskimo.com/~scs/C-faq/top.html
c.l.c++ FAQ: http://www.parashift.com/c++-faq-lite/
May 10 '07 #21
"Bart van Ingen Schenau" <ba**@ingen.ddns.infowrote in message
news:19****************@ingen.ddns.info...
Richard Heathfield wrote:
>Malcolm McLean said:
>>"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:As*********************@bt.com...
Malcolm McLean said:

<snip>

As a little intellectual exercise, can you now list some good
arguments for casting malloc()?

No. I tried hard to think of even a single good reason, and failed.
P J Plauger, however, can give one good argument for *P J Plauger*
casting malloc.

I was converted from malloc() casting to non-casting. However, as you
say, some very competent people do retain the cast.

I only know of one competent person who retains the cast. P J Plauger.
And even he does not advocate to cast the return value from malloc in
general.
To my knowledge, his reason for retaining the cast stems from such an
exceptional situation that it actually *confirms* the rule for not
casting the return value of malloc.
One reason he gave was that ANSI permitted the implict cast. OK. I
surrender, _conversion_, reluctantly, and knowing that they were driving a
coach and horses through the type-checking system.
That seems a pretty general reason to me.
However it is only a stupid committee that can't even come up with a
standard anyone wants to implement, so that particular justification seems
rather weak.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

May 10 '07 #22
Malcolm McLean wrote:
One reason he gave was that ANSI permitted the implict cast. OK. I
surrender, _conversion_, reluctantly, and knowing that they were driving a
coach and horses through the type-checking system.
/Casts/ (of pointer types) give you a coach-and-horses -- nay, a veritable
battleship -- to drive with. Allowing an implicit conversion doesn't seem
to make a significant difference and, by removing the necessity to cast
where `void*` is involved, make it, I think, less likely that casts between
non-void-* pointers will appear as a path of less resistance.

--
"It's just the beginning we've seen" - Colosseum, /Tomorrow's Blues/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

May 11 '07 #23
Groovy hepcat sa*****@yahoo.co.in was jivin' on Tue, 08 May 2007 22:19:16
-0700. It's a cool scene! Dig it.
#include <stdlib.h>

int main()
{
char *p = (char*)malloc(100);
if(p==NULL)
{
printf("...null...\n");
}
else
{
printf("...success...\n");
printf("1.%d\n",p[10]);
memset(p,0,101);
printf("2.%d\n",p[10]);
free(p);
printf("3.%d\n",p[101]);
All these printf() calls cause undefined behaviour, since you have
neglected to include stdio.h.
}
A C90 compiler is required to issue a diagnostic for a non-void
function without a return statement. In C99 it is permissible to leave
out a return statement in main(). However, there are apparently very few,
if any, C99 compilers. So chances are you don't have one. In either case,
it's always been a good idea to put at least one return statement in
main(). Return 0 or EXIT_SUCCESS to indicate successful execution and
EXIT_FAILURE to indicate termination due to an error. Those macros are
defined in stdlib.h, which you have included.
}

I used gcc on Solaris OS and i get the following output,
[Snip.]

You needn't get any output at all. Your program needn't even
successfully compile.

--
Dig the sig!

----------- Peter 'Shaggy' Haywood ------------

Ain't I'm a dawg!!
May 13 '07 #24

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Alex Vinokur | last post by:
Hi, I have a problem with invoking an instance before main() when using memory allocation for static member. Is the program below valid? =========================================== Windows...
10
by: Vishal Grover | last post by:
Hello Everyone, I am seeing a certain behaviour which I find strange, and am curious to get an explanation to it. I have the following program. #include <iostream> #include <cstdlib> using...
12
by: jois.de.vivre | last post by:
Hi, I have the following piece of code that is designed to help me add debug traces to my program (I wanted to use purely C++ code, but the only way I know how to do something like this is with...
4
by: Sameer | last post by:
Hello Group, This is one problem in programming that is troubling me. there is a segmentation fault just before creating memory to a structure ..i.e, just after the "allocating memory "...
19
by: tweak | last post by:
I have been messing around with buffers, and I found it peculiar that the code below will run without a segmentation fault. As far as I know, overwriting the allocated space from a call to...
7
by: Dan Nilsen | last post by:
Hi! I'm writing a small piece of software that basically runs on an embedded system with a Power-PC cpu. This runs on a stripped down version of Linux - Busybox. As I'm writing a piece of...
17
by: dtschoepe | last post by:
Hi, I have a homework project I am working on, so be forwarned, I'm new to C programming. But anyway, having some trouble with a memory allocation issue related to a char * that is a variable...
1
by: Dameon99 | last post by:
Hi, I have just spent many hours debugging my code and now when I run it I get the following error: "An access violation (Segmentation fault) raised in your program" I have researched on this...
5
by: paragon.john | last post by:
Hello all, I am trying to read a file into some allocated memory as part of a program and I am running into a problem. The program gets a segmentation fault during fread. I have previously...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.