Talk:Segmentation fault

Request for Citation in Overview

The second paragraph of the overview reads;

The term "segmentation" has various uses in computing; in the context of "segmentation fault", a term used since the 1950s, it refers to the address space of a program.[citation needed]

Since the sentence has three phrases I'm not clear on whether the citation is needed for the assertion segmentation has various uses in computing, that it's been used since the '50's or that it refers to the address space of a program.

Martinkunev does not explain.

Not an experienced Wikipedia editor so unsure if the tag should get removed with an explanation or this is just my hyperactive pedantry gland.

Netscr1be (talk) 13:59, 5 September 2014 (UTC)

Stack overflow through infinite loop?

This article from July 31, 2012, says that an Access Violation may occur due to "exceeding the allowable stack size (possibly due to runaway recursion or an infinite loop)". I'm fine with the runaway recursion, but infinite loops? Maybe someone should provide an example. StuartRedmann (talk) 09:24, 31 July 2012 (UTC)

Prescriptive/Normative discourse vs Reality

The current text is dominated by kernel theoreticians. Also, the merger of segmentation fault and bus error is very unfortunate. A bus error belongs into the _a_very_bad_thing_is_happening_close_to_the_hardware_category, while the segmentation_fault is invariably a programmer's fault. As an example, in many Unix implementations, deletion of a binary program file while it is running leads to a bus error. Such practical knowledge is nowhere to be found. I can tell it my students (they _will_ move a new version of a binary into the directory of an already running instance) but that insight is regularly removed from wikipedia. So get lost, I give up. — Preceding unsigned comment added by 129.125.178.72 (talk) 15:13, 10 April 2012 (UTC)

Misleading name

I think that POSIX's term "segmentation fault" is a misleading name to this event. Technically it's a "paging fault" on PC computers with Intel/AMD x86/x64 CPU, because it is an error in process of paging, not segmention. Linux for example doesn't use segments at all, so how it could make a segmentation fault? You can generate a technically proper segmentation fault on Linux only by using 48bit far pointers, but they aren't used in GCC compiler at all, are they? Surely the Microsoft's name "access violation" for the situation is better. In addition, Intel calls this event "page fault" and I am sure it has its own page here at wikipedia. In general, it is a situation when we do an invalid memory access. I think that this page is too Posix oriented and C-language centric, and doesn't clearly describe what segmentation fault really is. I think it should just contain a short information that it is a POSIX's term for bad memory access and link to other wikipedia pages where it is better described in general non C-centric point of view. AleyCZ (talk) 02:07, 8 December 2009 (UTC)

The original term (used since the fifties) is segmentation fault. In this case, "segment" does not refer to the physical "segments" of the CPU (considering that the original PDP-11 that UNIX was implemented on (before the x86 even existed) had no CPU segments either) but to the various parts of an executable, like ".bss" and ".data" segments (also called sections). A "paging fault" is an even more misleading name because segmentation violations can happen on systems that don't use paging (but still have executables divided into segments), and because programs do not necessarily need to access an invalid page to cause a segfault. A segmentation fault can also occur in the middle of a page, by overwriting a sentinel or other data, which is why writing one element beyond an array's limit can cause crashes (segfaults) and why mallocing a few bytes doesn't mean you can use all addresses rounded up to the next page. —Preceding unsigned comment added by 69.54.60.34 (talk) 20:05, 23 March 2011 (UTC)

The original term *on UNIX*. The wikipage should be fixed to clarify that "segfault" is a term used by *NIX-like systems. There are plenty of other systems, some quite a bit older, that had their own terms before UNIX was conceived. 192.19.207.250 (talk) 13:20, 20 February 2024 (UTC)

Additionally, page faults can happen without Segmentation Faults, for example if a file is mmapped, then accessing the memory at the mapped virtual address could generate page faults that the kernel is going to resolve by performing the corresponding IO operations, then associating a chunk of actual memory. --165.85.177.204 (talk) 17:09, 26 January 2024 (UTC)

What is a segmentation fault ?

Why does the Turbo C compiler doesn't shows it while it is rampant in the GNU compiler? —Preceding unsigned comment added by 203.76.128.203 (talk • contribs)

It is nothing to do with compilers, it is an operating system thing. NicM 07:35, 28 April 2006 (UTC).

If we are talking about C, then you're wrong; it is entirely possible for two compilers that compile to the same platform to produce a program that behaves differently, and "platform" includes both the operating system and the processor model. So you can have a program that segfaults with one compiler and does not segfault with another, on the same platform, and that's without regarding any issues of optimization.

You are right inasmuch that Turbo C is a DOS-only compiler, and DOS and the processor models it runs on do not have any protection mechanisms (so segfaults simply cannot occur), while GNU C is a compiler that, to my knowledge, has never been ported to 16-bit DOS, so the OP is definitely talking about different platforms. (DJGPP is a GNU C port for 32-bit protected mode, so it's not relevant here.) 82.92.119.11 13:02, 6 May 2006 (UTC)

I am not wrong at all. The fact that different compilers produce different code does not make segfaults anything more than an interaction between running code and the platform on which it is running. Sure, compilers can produce different code which may segfault, or through a bug or programmer error produce code that ends up with a segfault, but that doesn't redefine segfault to make it a direct product of the compiler. A segfault is is an attempt to illegally access protected memory, nothing more. For normal users they are as often caused by hardware faults as incorrect code or compiler bugs. NicM 07:03, 2 June 2006 (UTC).

I simply contradicted your statement that "it has nothing to do with compilers". It does at least have something to do with the compiler, inasmuch that one compiler can turn a program into object code which consistently segfaults while another does not (even assuming the hardware and both compilers are flawless). I don't dispute the fact that the segfault isn't a direct product of the compiler, and I never claimed that it was. I pick my nits very carefully. :-)

The OP, of course, was just confused about the nature of segfaults; programs compiled with Turbo C never segfault because the object code runs on a platform that doesn't have a concept of protected memory, but this is an implementation accident. I was just pointing out that your statement wasn't strictly correct. 82.92.119.11 20:41, 8 June 2006 (UTC)

The GNU compiler doesn't run on dos. Compiling the program in GNU necessarily means that it was compiled on a different operating system than the program compiled by Turbo C. Even if it has has the same hardware and both compilers are flawless.

I'm not acquainted with whether or not the compiler can effect seg faults (I actually would think it could), but the logic here is completely flawed. You completely ignored, or maybe even didn't understand, the previous posts. If it is true, it's not because of the whole turbo C vs gcc thing.

This page should most certainly be merged with that for Access violation; the terms are synonymous. Since the page Segmentation fault is the more detailed of the two, including all information presented by that for Access violation, I propose that the latter simply be linked to the former.74.131.87.98 22:37, 1 June 2006 (UTC)

I agree. Access violation is also misleading wrt segments. NicM 07:06, 2 June 2006 (UTC).

I've redirected Access violation to here, per this discussion. Kevin 08:40, 24 June 2006 (UTC)

Category:Null pointer

The second code sample does not necessarily initialize a pointer to address zero. It initializes it using the null pointer constant, which sets it to a value which cannot represent a valid memory address. That is not necessarily address zero.

See C FAQ:

http://c-faq.com/null/null1.html

and

http://c-faq.com/null/accessloc0.html

131.128.160.100 (talk) 19:07, 20 February 2008 (UTC)

OpenBSD vs. Linux ?!?

What's the point of comparing gcc's behaviour under OpenBSD vs. Linux? AFAIK the presence of absence or a compilation-time error has nothing to do with the OS, it depends on the behaviour of different gcc versions.--88.149.248.200 (talk) 02:51, 29 February 2008 (UTC)

But a segmentation fault is not a compile time error, Its a runtime error. —Preceding unsigned comment added by 124.150.80.158 (talk) 03:07, 21 March 2008 (UTC)

Sorry you are right in the version that is run on linux it is picked up at compile time --124.150.80.158 (talk) 03:09, 21 March 2008 (UTC)

Solution

Why don't we have a section after the example that shows how to do avoid the error?: After the segfault output, have: {{{

  char stack s;
  char *s = &stack_s;
    *s = "hello world";
    *s = 'H';

}}} This safely creates the variable s_stack on the memory stack, points variable s to it, produces no such error. (Can someone please verify that this is correct practice / fix it if necessary?) —Preceding unsigned comment added by 132.185.240.123 (talk) 11:13, 30 June 2008 (UTC)

I second this idea, even though it was proposed months ago. Would somebody be against it ?Felip Manyé i Ballester (talk) 20:33, 23 December 2008 (UTC)

This 4 lines of code doesn't "fix" anything, as line 3 is an absolute nonsense. You cannot assign a literal string to a char variable. If you want to change contents of memory, you simply need to declare an array. That's it, just use arrays when you need to manipulate memory.

 char []a = "hello world";
 *a = 'H';

AleyCZ (talk) 01:54, 8 December 2009 (UTC)

Difficult to Read

This article is a bit hard to read. In particular, the paragraph

On Windows machines the "read/write" operations on hard-coded text string are available. System does not see anything wrong within the above code. Just the first letter of a text string "hello world" is replaced with another letter 'H' (for both C & C++). No memory violation occurs. But, if you start to move the 's' pointer forward (like using s++ directive inside a loop) and you pass over the final NULL value, that ends up each text string (including "Hello World"), then if you try to write another letter, you should receive the "Segmentation fault error".

This paragraph sounds technical, and has a few grammar errors reducing the legibility further. I am tempted to edit the grammar errors out, but I fear that for lack of knowledge on the subject, I might change the meaning. ShinyCharz (talk) 01:13, 13 May 2009 (UTC)

Needs revision

Most of the information in the "Examples" section of this article is ambiguous and misleading. A “Segmentation fault” is nothing more than an invalid page fault and the OS has chosen, via exception or other means, to close the process that generated the fault. See the Wiki page on “Page fault”, “General protection fault”, and “Bus Error” for a better idea of what is going on. This article should be shortened and contain only the information needed to specifically describe the condition and redirect to “Page fault”, “General protection fault”, and “Bus Error” where appropriate to clarify. The first paragraph is pretty good, the rest is in question. If I don't see any complaints in the next few days I will revise the article. Karl McClendon (talk) 17:31, 19 September 2009 (UTC)

Bus error

Bus error and segmentation fault are similar. Expert C programming: deep C secrets By Peter Van der Linden : Both error occur when hardware tells the OS about a problematic memory reference. I'm going to merge bus error here and create the redirect. AgadaUrbanit (talk) 21:13, 24 August 2010 (UTC)

I’ve resplit these articles – these are related topics, but they are distinct: distinct signals and distinct causes. Further, each fault has multiple possible causes, so one ends up with a long and confusing list of causes. The existing merged article was hard to read, as it just listed the two topics one after the other (after over 3 years of being merged), and would be clearer separately. Further, segmentation faults are extremely common, and of wide interest – every C programmer and many, many users have experienced these – while bus errors are, at present, much more technical (this is the first time I’d heard of bus errors). Thus merging the articles distracts from a key point of interest, namely what are segfaults.

Does this seem reasonable?

That said, there should be a clear (and brief) discussion at the individual articles about how these faults differ. I’ll do this post-splitting.

—Nils von Barth (nbarth) (talk) 01:51, 26 January 2014 (UTC)

File:Windows null ptr dereference.png Nominated for speedy Deletion

An image used in this article, File:Windows null ptr dereference.png, has been nominated for speedy deletion for the following reason: All Wikipedia files with unknown copyright status What should I do? Don't panic; you should have time to contest the deletion (although please review deletion guidelines before doing so). The best way to contest this form of deletion is by posting on the image talk page. If the image is non-free then you may need to provide a fair use rationale If the image isn't freely licensed and there is no fair use rationale, then it cannot be uploaded or used. If the image has already been deleted you may want to try Deletion Review This notification is provided by a Bot --CommonsNotificationBot (talk) 21:10, 2 December 2011 (UTC)

Common causes

First bullet: this sentence "Note that while most compilers will not output a binary given a compile-time error; " sounds not complete, or maybe it should read "Note that most compilers will not output a binary given a compile-time error," --46.115.36.53 (talk) 22:09, 12 August 2012 (UTC) Marco Pagliero Berlin

Biased sentences

I'm quoting here, but by reading this article, I find pearls like this:

″Segmentation faults are a common class of error in programs written in languages like C that provide low-level memory access and few to no safety checks.″

″Many programming languages have mechanisms designed to avoid segmentation faults and improve memory safety. For example, Rust employs an ownership-based[2] model to ensure memory safety.″

It seems that this article is just selling Rust over C, when a segmentation fault can happen regardless of the language a given program was written in. This clearly has no encyclopedic value. A segmentation fault can happen when a program access a memory space that shouldn't access, and there is that. It is possible on any language, including Rust. Programming languages are out of scope here. — Preceding unsigned comment added by 155.140.133.228 (talk) 13:52, 30 July 2024 (UTC)

It is possible on any language How would it be possible in, for example, a language with no pointers and with required array bounds checking? Guy Harris (talk) 23:12, 24 August 2024 (UTC)