I am a bit confused on this homework and the data structure of a stack. Essentially the question is:
"Give the output printed by java Stack for the input"
Below is the input
it was - the best - of times - - - it was - the - -
the output would be in the answer key
was best times of the was the it (1 left on stack)
I don't understand how you would receive this output I attempted writing my own stack structure but if I iterate through it I just get first in, first out.
Any help will do I would greatly appreciate it.
It isn't stated explicitly, but looking at the input I assume words are pushed onto the stack, while - signs are pop operations. If that is the case then the operations are
push it, stack contains it;
push was, stack contains it was;
pop prints was, stack contains it;
push the, stack contains it the;
push best, stack contains it the best;
pop prints best, stack contains it the;
push of, stack contains it the of;
push times, stack contains it the of times;
pop prints times, stack contains it the of;
pop prints of, stack contains it the;
pop prints the, stack contains it;
push it, stack contains it it;
push was, stack contains it it was;
pop prints was, stack contains it it;
push the, stack contains it it the;
pop prints the, stack contains it it;
pop prints it, stack contains it.
The words in bold are the output of the pop operations.
Related
I have written a function in C, which, when called, immediately results in a stack overflow.
Prototype:
void dumpOutput( Settings *, char **, FILE * );
Calling line:
dumpOutput( stSettings, sInput, fpOut );
At the time of calling it, stSettings is already a pointer to Settings structure, sInput is a dynamically allocated 2D array and fpOut is a FILE *. It reaches all the way to the calling line without any errors, no memory leaks etc.
The actual function is rather lengthy and i think its not worth sharing it here as the overflow occurs just as the code enters the function (called the prologue part, i think)
I have tried calling the same function directly from main() with dummy variables for checking if there are any problems with passed arguments but it still throws the stack overflow condition.
The error arises from the chkstk.asm when the function is called. This asm file (according to the comments present in it) tries to probe the stack to check / allocate the memory for the called function. It just keeps jumping to Find next lower page and probe part till the stack overflow occurs.
The local variables in dumpOutput are not memory beasts either, just 6 integers and 2 pointers.
The memory used by code at the point of entering this function is 60,936K, which increases to 61,940K at the point when the stack overflow occurs. Most of this memory goes into the sInput. Is this the cause of error? I don't think so, because only its pointer is being passed. Secondly, i fail to understand why dumpOutput is trying to allocate 1004K of memory on stack?
I am totally at a loss here. Any help will be highly appreciated.
Thanks in advance.
By design, it is _chkstk()'s job to generate a stack overflow exception. You can diagnose it by looking at the generated machine code. After you step into the function, right-click the edit window and click Go To Disassembly. You ought to see something similar to this:
003013B0 push ebp
003013B1 mov ebp,esp
003013B3 mov eax,1000D4h ; <== here
003013B8 call #ILT+70(__chkstk) (30104Bh)
The value passed through the EAX register is the important one, that's the amount of stack space your function needs. Chkstk then verifies it is actually available by probing the pages of stack. If you see it repeatedly looping then the value for EAX in your code is high. Like mine, it is guaranteed to consume all bytes of the stack. And more. Which is what it protects against, you normally get an access violation exception. But there's no guarantee, your code may accidentally write to a mapped page that belongs to, say, the heap. Which would produce an incredibly difficult to diagnose bug. Chkstk() helps you find these bugs before you blow your brains out in frustration.
I simply did it with this little test function:
void test()
{
char kaboom[1024*1024];
}
We can't see yours, but the exception says that you either have a large array as a local variable or you are passing a large value to _alloca(). Fix by allocating that array from the heap instead.
Most likely a stack corruption or recursion error but it's hard to answer without seeing any code
My teacher gave me some code and I have to run it and make it jump to the admin section using a buffer overflow. I cannot modify the source code. Could someone explain how I could jump to the admin method using a buffer overflow? I'm running it on ubuntu 8.10 and it was compiled with an older version of gcc so the overflow will work.
Without being able to see the code, on a general level you need to design inputs to the function that will overwrite the return address (or another address to which control will be transferred by the function) on the stack.
At a guess, the code has a fixed length character buffer and copies values from a function parameter into that buffer without validating that the length does not exceed the length of the buffer.
You need to make a note of what the stack layout looks like for your application (running it under a debugger may well be the quickest way to do this) to work out where the address you need to override is, then put together a string to overwrite this with the address of the admin function you need to call.
You can always get the asm output of it (I forgot how right now... brainfart) and see where the buffer you want to overflow is being used/read and check it's length. Next you want to calculate how far you need to overflow it so that you either replace the next instruction with a JMP (address of admin code) or change a JMP address to that of the admin section. 0xE8 is the jump opcode for x86 if you need it since you want to overwrite the binary data of the instruction with your own.
I just started using applescript today, and heard about subroutines. So I decided to write a little test program that takes a number, increments it by 9, subtracts 27, divides by 3, and then returns the result. Only it doesn't return the result; it returns a StackOverFlow error instead. What is a StackOverFlow error?
The program compiled correctly, and I don't know what is wrong. Like I said, I'm very new to applescript. Here is the code that I'm running:
calculate_result(text returned of (display dialog "Enter a number:" default answer ""))
on calculate_result(this_result)
set this_result to this_result + 9
set this_result to this_result - 27
set this_result to this_result / 3
return calculate_result(this_result)
end calculate_result
An excerpt from an answer to a similar question...
Parameters and local variables are allocated on the stack (with reference types the object lives on the heap and a variable references that object). The stack typically lives at the upper end of your address space and as it is used up it heads towards the bottom of the address space (ie towards zero).
Your process also has a heap, which lives at the bottom end of your process. As you allocate memory this heap can grow towards the upper end of your address space. As you can see, there is the potential for the heap to "collide" with the stack (a bit like techtonic plates!!!).
A Stack Overflow error means that the stack (your subroutine) overflowed (executed itself so many times that it crashed). Stack Overflow errors usually result from a bad recursive call (in the case of AppleScript, a bad subroutine call).
In general, if your subroutines return values, make sure that value is not the subroutine name. Otherwise the stack will overflow, crashing your program (if the return statement is not inside a try block). Just change this:
return calculate_result(this_result)
...to this
return this_result
...and you should be good to go!
In some cases it is fine to return the subroutine name, but only if there is a terminating condition. For example, if a user entered an invalid number, the subroutine could rerun itself, but only if the number was invalid (shown below):
on get_input()
set this_number to null
try
set this_number to the text returned of (display dialog "Please enter a number:" default answer "") as number
on error --the user didn't enter a number and the program tried to coerce the result into a number and threw an error, so the program branches here
return get_input()
end try
return this_number
end get_input
In the above case, the terminating condition occurs when a user enters an actual number. You can usually tell when a program will throw a Stack Overflow error because there is no terminating condition.
I hope this information helps!
In "calculate_result", the last line is calling "calculate_result" again. Change the line to:
return (this_result)
The last line in the subroutine is just calling the subroutine again, which calls the subroutine again, which calls the subroutine again, which calls the subroutine again, which calls the subroutine again...
I think you get the idea - the AppleScript, as you've written it - crashes because it just keeps calling itself, and eventually runs out of memory, hence triggering the stack overflow error.
A stack overflow error happens anytime a program runs out of a certain kind of memory space - it's not specific to AppleScript - it can happen in any programming language. See this answer for a more in-depth explanation of a stack overflow error is:
( What is a stack overflow? )
return calculate_result(this_result)
You are recursively calling the subroutine again passing this_result to it and the called function in turn calls the sub-routine and so on. Variables, return address of the function etc., resides on stack. And due to the recursive nature of the sub-routine the stack overflows.
Here is the project page
http://www.codeproject.com/KB/threads/StackWalker.aspx
[STACKFRAME64][1] s;
//s contains the current stack frame filled by calling [StackWalk64][2] WinAPI
if (s.AddrPC.Offset == s.AddrReturn.Offset)
{
printf("StackWalk64-Endless-Callstack!");
}
My question is when will this condition be satisfied? What addresses do s.AddrPC.Offset, s.AddrReturn.Offset contain?
Is the return address in the last frame on stack = 0?
Hopefully never, but it is a basic sanity check in case the stack frame got stomped. Which isn't unlikely when you try to walk the stack in an exception handler triggered by a nasty hardware exception like AccessViolation. Without that check the code would enter an endless loop, constantly finding the same stack frame back.
AddrPC is the address of the call instruction, AddrReturn is the return address, the address of the previous call instruction (+5). Not sure what "stack 0" might mean.
I've been using SetUnhandledExceptionFilter for a long time, and my handler walks the stack and uses dbghelp.dll to convert the addresses into File/Line references. It then writes that to a log file and puts up a dialog with the same information for the user. This USED to work just fine. These days however I'm getting a completely useless stack:
1004bbaa: Lgid.dll, C:\Data\Code\Lgi\trunk\src\win32\Lgi\LgiException.cpp:175
10057de0: Lgid.dll, C:\Data\Code\Lgi\trunk\src\win32\Lgi\GApp.cpp:107
7c864191: kernel32.dll, UnhandledExceptionFilter+0x1c7
102158ed: MSVCRTD.dll, winxfltr.c:228
006dc1a7: Scribe.exe, crtexe.c:345
7c817077: kernel32.dll, RegisterWaitForInputIdle+0x49
00000000: Scribe.exe
Where 'Scribe.exe' is my application. Now if I walk the debugger from the exception handler back up the stack several frames I eventually get to a completely different temporary stack that actually includes all the calls that led up to the crash. Which is the information I actually want to log for the user. It's as if the exception handler is executing on a separate stack from the main application.
What I need is the stack information for the actual application stack, that includes all the calls leading up to the crash. Is there some easy way to get that from inside the exception handler?
According to http://www.eptacom.net/pubblicazioni/pub_eng/except.html I can get the exception's EIP and EBP out of the EXCEPTION_POINTERS 'Context' member. So I tried passing that EBP to my stack walker as it's initial point and it could then walk the application stack correctly. As long as I put the EIP as the first point in the stack walk I get the whole thing.
Are you using x64? Could you be hitting http://blog.paulbetts.org/index.php/2010/07/20/the-case-of-the-disappearing-onload-exception-user-mode-callback-exceptions-in-x64/ ?