I have a program that uses linked lists. It crashes with External:SIGSEGV when it gets to
new(R);R:=queue;queue:=queue.Next;dispose(R);
where I'm getting rid of the first element of the queue list, after dispose(R). What's even more weird - when I change it to queue:=queue.Next that is, just moving forward without dumping the element - it still crashes, after this command. It's worth mentioning that the value of queue.Next=nil. And when I tried just queue:=nil; it crashed too, leaving me absolutely puzzled. Can somebody help me?
Edit: I've uploaded the whole code here, relevant line is no. 128.
The problem was that I was dereferencing the pointer later and lazarus wasn't able to backtrack to that position so he pointed at the line where the pointer was set to nil.
Related
Looked around with numerous search strings but can't find anything quite like this:
I'm writing a custom log parser (ala analog or webalizer except not for webserver) and I want to be able to skip the hard work for the lines that have already been parsed. I have thought about using a history file like webalizer but have no idea how it actually works internally and my C is pretty poor.
I've considered hashing each line and writing the hashes out, then parsing the history file for their presence but I think this will perform poorly.
The only other method I can think of is storing the line number of the last parse and skipping until that number is reached the next time round. What happens when the log is rotated I am not sure.
Any other ideas would be appreciated. I will be writing the parser in ruby but tips in a similar language will help as well.
The solutions I can think of right now are bound to be brittle.
Even if you store the line number and later realize it would be past the length of the current file, what happens if old lines have been trimmed? You would start reading (well) after the last position.
If, on the other hand, you are sure your log files won't be tampered with and they will only be rotated, I only see two ways of doing what you want, and I'm not sure the second is applicable to you.
Anyway, here goes.
First solution
You store the last line you parsed along with a timestamp. At the next run, you consider all the rotated log files sorting them by their last modified date, figure out which one you read last time, and start reading from there.
I didn't think this through, there might be funny corner cases you will need to handle.
Second solution
You create a background script that continuously watches the log file. A quick search on Google turned out this gem, but I'm not sure if that's even an option for you. Even then, you might want to integrate this solution with the previous one just in case your daemon will get interrupted (because that's clearly bound to happen at some point).
As you read the file and parse the lines keep track of the byte count. Save that. On next read, try to seek to that byte offset in the file. If the file is smaller than the byte count, it's a new file so start at the beginning.
Maybe it's just a stupid case of PEBKAC, but recently, when fixing C# compiler errors, I frequently run into this problem:
I press enter on the first error (to jump to the code and fix it)
The error gets removed from the list (still normal for JIT code)
Previously, I would now just shortcut to the Error list, press down once, then Enter and fix the next bug. But now the list just seems to put my selection at a random error, not at the next one in the file.
I have the list sorted by error number (2nd column) which seems to coincide with File and Line sorting. I'm using VS2013.
Maybe I changed some setting by accident? Or is that a VS2013 bug? (Haven't been using it for that long, and 2008 never had that problem AFAIK)
PS: It could be the case that that problem has always existed, but I didn't notice because it doesn't happen in C++ obviously, and I didn't have such a mass of errors at once (big refactoring atm)
setvbuf (stdout, NULL, _IOLBF, 0);
This line is present in one of my codes and I am not able to figure out why. If I comment out this line, my app works fine. But if I keep it, then my app crashes. Also read http://msdn.microsoft.com/en-us/library/86cebhfs(v=vs.100).aspx, but not able to understand properly, as to why the application is crashing.
Please help.
Thanks
Part of the MSDN description for setvbuf() says:
So, on Windows, you will get the same effect as _IOFBF, which, as it says in the text, will use an automatically allocated buffer of the size you specified.
In your code, you specified a size of zero. Hence the crash.
On non-Win32 systems, the same command would activate line buffering and so possibly would be ok. Perhaps this code is multi-platform?
I have this really nasty bug in my program, which somehow changes the value of my variable. I have tried setting break points but can't find the line of code that's the culprit.
Is there any way to pause program execution when there's a line of code that's changing the value of a variable in Xcode 4?
One way would be to find the value changing operations or in general any bug using bisection. Ie. you choose two breakpoints that have the problematic operation in between and move one of them to middle and check if the value still changes. If it does repeat in this halt, if not repeat in the other half.
I was debugging a crash in my HID driver code on the Mac and found that the crash happened in the CFRunLoop. In the driver code I open the USB handles for the devices which match the VID and the PID which match my HID device and then set up an Interrupt call back for it using setInterruptReportHandlerCallback function and then add it to the CFRunLoop using CFRunLoopAddSource call. In my call to the close handles I freed them up using CFRunLoopRemoveSource and then a CFRelease on the CFRunLoopSourceRef .
The problem occurs when I try to Open the handles wait for a while( 5ms) and then close the handles in a loop.
When I searched for the problem I came across a link where they had a similar problem to mine http://lists.apple.com/archives/usb/.../msg00099.html where they had used CFRunLoopSourceInvalidate call instead of teh Remove Source call. When I changed it to Invalidate source in my close handles call, it fixed my crash. I wanted to know what is the difference between the crash and why this call fixed my crash?
Thanks
jbsp72
First, let me thank you. I type CFRunLoopRemoveSource in google, find your message which is exactly the problem I was trying to solve, and your solution by calling CFRunLoopSourceInvalidate instead also solves my problem.
Now, the difference between CFRunLoopRemoveSource an CFRunLoopSourceInvalidate is:
CFRunLoopRemoveSource removes the
source from the specific run loop you
specify.
CFRunLoopSourceInvalidate renders the
source invalid, and will remove it
from all the run loops where was
added.
Now, the crash, which I suspect is the same as the one I got, is that the run loop the source was added to has disappeared, and trying to remove the source from it results in a crash. Actually, an infinite loop in __spin_lock in my case.
Now, how can a run loop disappear? Run loops are tied to threads. You create a new thread, you have a new run loop, automatically. If a thread ends, the run loop disappears with it. The thread I attached the run loop to has exited, and subsequently removing the source from the run loop results in the crash.
The reason why invalidating the run loop solves the problem is because it removes the source from all the run loops it was added to, ignoring run loops that now do not exist anymore.