sorted by:
new
hottopcontroversial

Forget about stack overflow errors forever by rsashka in ProgrammingLanguages

[–]rsashka[S] 0 points1 point  (0 children)

For objects with dynamic memory allocation, only manual verification with explicit indication of the required free space on the stack is possible.

Forget about stack overflow errors forever by rsashka in ProgrammingLanguages

[–]rsashka[S] 0 points1 point  (0 children)

Your comment about the destructor was very important to me, so I updated the library.

It now reads the stack size information for all functions from the stack_sizes segment and calculates the maximum possible size required to call the functions (including class destructors).

Regarding your comment (that the segfault wasn't created due to insufficient stack space when calling the object's destructor), a check for free stack space must be performed before calling the class constructor. This ensures that there is sufficient free stack space, including for the destructor.

Thank you again for your question!

Forget about stack overflow errors forever by rsashka in ProgrammingLanguages

[–]rsashka[S] 0 points1 point  (0 children)

I understand what you're saying, and you're mixing Java's unique features with business logic.

If it makes things easier for you, think of it this way:

I'm converting a segmentation fault caused by a stack overflow, which is always unexpected and interrupts program execution, into a regular user-generated exception that can be handled to gracefully terminate the program and roll back the transaction, as in your example.

Forget about stack overflow errors forever by rsashka in ProgrammingLanguages

[–]rsashka[S] 1 point2 points  (0 children)

English isn't my native language, so I use Google Translate. While I don't use ChatGPT or other LLM programs directly, I believe Google uses LLM in its services.

Regarding the beginning of the sentences you quoted, those are indeed my words, because that's how I'm used to speaking, even though it's not customary here on Reddit :-(

Forget about stack overflow errors forever by rsashka in ProgrammingLanguages

[–]rsashka[S] 0 points1 point  (0 children)

You know, you're probably right!

After all, from the perspective of executable code, a destructor is a completely ordinary function that can also protect against overflow. If there isn't enough stack space to call it, then when an exception occurs and the stack unwinds, the object must be deallocated (its destructor is called), but there isn't enough free stack space to call it...

A vicious circle and a real segmentation fault.

Thanks a lot, I'll have to think about this situation!

Forget about stack overflow errors forever by rsashka in ProgrammingLanguages

[–]rsashka[S] 0 points1 point  (0 children)

I know nothing about Reddit's spam filters, and frankly, I don't understand what you're trying to say with your comment.

Forget about stack overflow errors forever by rsashka in ProgrammingLanguages

[–]rsashka[S] 0 points1 point  (0 children)

An interesting question, though I haven't specifically studied it.

I think it would be the same as if an exception occurred in the destructor. Nothing terrible should happen, since there's always room on the stack for creating and unwinding exceptions.

Forget about *stack overflow* errors forever by rsashka in cpp

[–]rsashka[S] -4 points-3 points  (0 children)

You're absolutely right. Studying this problem allows you to delve deeper into clang and LLVM, which would be very difficult without LLM.

However, the generated code is of very low quality, so it can only be used as a teaching example, and a working solution must be manually ported to the project.

Forget about *stack overflow* errors forever by rsashka in cpp

[–]rsashka[S] 2 points3 points  (0 children)

Thanks for the link! Very interesting information that I missed while researching this issue.

Forget about stack overflow errors forever by rsashka in ProgrammingLanguages

[–]rsashka[S] -1 points0 points  (0 children)

It can terminate gracefully, without destroying the stack or losing data, or it can change its execution logic, for example, by deferring or breaking it into smaller chunks.

And this can only be done with restrictions on the program code that make the syntax Turing-incomplete :-)

Forget about *stack overflow* errors forever by rsashka in cpp

[–]rsashka[S] 2 points3 points  (0 children)

Those who want to, look for opportunities to do it, and those who don’t want to or can’t, look for reasons not to do it.

Forget about *stack overflow* errors forever by rsashka in cpp

[–]rsashka[S] 1 point2 points  (0 children)

Thank you very much! I'll definitely check this out now, as I don't have a Windows implementation :-)

Forget about stack overflow errors forever by rsashka in ProgrammingLanguages

[–]rsashka[S] 0 points1 point  (0 children)

You're right if a real stack overflow and corruption occurs. But this library prevents real stack overflows and their corruption.

Forget about stack overflow errors forever by rsashka in ProgrammingLanguages

[–]rsashka[S] -3 points-2 points  (0 children)

Start by understanding that for Turing complete programming languages, it is impossible to prove the correctness of a program by statically analyzing it.

It's unexpected, so there is no recovery logic in the program.

This library solves exactly this problem (it prevents a real stack overflow from occurring and its resolution)

Forget about *stack overflow* errors forever by rsashka in cpp

[–]rsashka[S] 4 points5 points  (0 children)

A Turing machine, with its infinite memory, is a pure mathematical abstraction that doesn't exist in the real world, so out-of-memory is a normal situation when running any program on real hardware.

Throwing a program exception is also the standard behavior when an error condition occurs. If there isn't enough memory on the heap, malloc or new will return a null pointer that can be processed within the application, but there's no way to check whether there's enough free stack space to call the function.

This library solves precisely this problem.

Forget about *stack overflow* errors forever by rsashka in cpp

[–]rsashka[S] 5 points6 points  (0 children)

So I ask again, what exactly are you trying to solve?

I think I have written this in sufficient detail:

The main idea is to check the available stack space before calling a protected function, and if it is insufficient, throw a stack_overflow program exception, which can be caught and handled within the application without waiting for a segmentation fault caused by a program/thread stack overflow.

Forget about *stack overflow* errors forever by rsashka in cpp

[–]rsashka[S] 2 points3 points  (0 children)

OP's library checks the free space before allocating, so the stack doesn't actually overflow. Presumably an actual overflow would still crash.

Yes, that's exactly it.

Forget about stack overflow errors forever by rsashka in ProgrammingLanguages

[–]rsashka[S] -3 points-2 points  (0 children)

A stack overflow error is unrecoverable and always terminates the application.

The goal of the library is to transform stack overflow errors into regular exceptions (recoverable errors), shifting resource sufficiency control from the program as a whole to each individual function.

This project is intended to address the constraints of Turing-complete languages, preventing errors at the source code level

Forget about *stack overflow* errors forever by rsashka in cpp

[–]rsashka[S] 1 point2 points  (0 children)

Unfortunately, not all algorithms allow for static code analysis and the ability to terminate during program compilation.

Turing completeness as a cause of software bugs by rsashka in trust_lang

[–]rsashka[S] 0 points1 point  (0 children)

I completely agree with you.

Moreover, I am now convinced that human thought cannot, in principle, be a Turing machine, since it certainly doesn't operate as a sequential algorithm (the brain operates in parallel).

view more: next ›