I have a VxWorks 5.5.1 project on a MPC862 processor using dosFsLib and getting the bootsec array fails intermittently. In investigating this issue, I get to the call to cbioBytesRW which is in cbioLib.c. So far so good.
My issue is that in cbioLib.c, the function cbioBytesRW calls the cbioDevBytesRW function pointer to perform the read of the the bootsec array and I cannot find where cbioDevBytesRW is initialized.
I have used "ar" and looked into target/lib/ppc/PPC860/common/libos.a but dont see it in the library either.
Can someone help me undertand how cbioBytesRW is initialized, please?
Charles Krinke
Related
I am a second year Computer Programming student who is working on a program in Objective C. (Xcode, if it matters). Right now, we are working on animation and moving animated objects across the screen. Right now, I am dealing with an error that is driving me insane. My program is using ARC, Automated Reference Counting, which supposedly is supposed to help with memory management. However, for some reason, I can't seem to use
[super dealloc];
It always gives me an error that says "ARC forbids explicit message send of 'dealloc'
Why is this? How do I fix it? It works in my other programs, just not this one?
Also, release doesn't seem to work either. For example, the following code gives me 2 errors:
[fireBall release];
The error says "'release' is unavailable: not available in automatic reference counting mode" and the next error says "ARC forbids explicit message send of 'release'." Why does this happen, how can I fix it? This code works in my other programs. Can someone please explain, or at least provide a link that can solve all my problems? Thanks for reading
You should take some time to fully go through Apple's Guide on ARC
It will save you tons of time and it's something definitely worth understanding.
You can define your own dealloc method, you just cant call [super dealloc] (ARC calls it automatically). The same is true for release, you dont need to call it as ARC handles placing it in your code
Simple, just remove that line. ARC takes care of all release/autorelease/dealloc calls.
ARC has 100% (pretty much) insight in the lifetime of your objects and inserts these calls for you.
You can still override the dealloc method to do some cleanup though.
The scenario is pretty straighforward, I've embedded mono runtime 2.10.8 in my app, and I'm calling the managed methods via pointers obtained by: mono_method_get_unmanaged_thunk:
// obtain pointer
bool (__stdcall*foo) (MonoException**);
foo = mono_method_get_unmanaged_thunk(somemethod);
// call it
MonoException* exc;
foo(&exc);
if(exc)
// handle exception
// nothing else...
What puzzles me, that I'm doing nothing else with the MonoException pointer (documentation I've read doesn't say anything about this). Is it removal handled by the managed runtime? If so, how it can be sure that my native side is not holding a pointer to it?
Edit
I've read through the sources and found out that exceptions are just pointers to objects created with mono_object_new, so they are subject of the garbage collection.
Now, I've also read that if I want to keep some pointer on native side and prevent it from being garbaged I need to obtain GC handle for it. So the (modified) question now is:
If the point of returned pointer to exception object is only to serve as error reporting facility, and such error reporting is made right after the managed call, is it safe to assume it won't get garbaged before I handle it (without using gc handle)?
To quote the page you linked:
Note that this registration is not necessary for LOCAL variables, as they are stored on the stack. It is only necessary for global variables, as they are not a part of the GC's root set.
So that means in your scenario you don't have to allocate a handle.
I'm looking to use FSPathCopyObjectAsync and I'm failing. In order to get my head around the problem I've been looking for examples of it elsewhere and although I was experimenting with the slightly dated source code from Matt Long's tutorial over on Cocoa is my Girlfriend, I then found a bit more elaborate example in a project on github, as a category on NSFileManager. Since my project is running under ARC, I tried porting it, and succeeded only at the half of it.
In its current form, the actual copying works, yet the callback method MZCopyFSPathFileOperationStatusProc is never called. That callback method happens to be the sole reason for using asynchronous copying, otherwise one might as well run a synchronous one in the background. I'm assuming the reason for the callback not being called is that some object is incorrectly released by ARC, but there could be something else going on. I am holding on to the return object of the copyItemAsyncAtPath:toPath:destName:options:statusChangeInterval:error: method, so that can't be it, right?
Who can spot the error and explain why this category isn't generating any callbacks? Is it ARC? Is it something else?
Much obliged. EP.
P.S. For redundancy reasons, here is the gist: https://gist.github.com/6f3715753896ccf6fd35
Your delegate needs to be strongly referenced by something. NSFileManager will only hold a weak reference to it (as it should do), so if you don’t have a strong reference to it, your delegate will get released and the callbacks won’t be seen.
Have you considered using blocks for the callbacks? That would probably be preferable.
i am working on an application which calls the COM component of a partner's application. Ours is .Net, theirs isn't. I don't know much about COM; I know that the component we're calling is late-bound i.e.
obj As Object = CreateObject("THIRDPARTY.ThirdPartyObject")
We then call a method on this COM object (Option Strict Off in the head of the VB file):
obj.AMethod(ByVal Arg1 As Integer, ByVal Arg2 As Integer, ByVal Arg3 as Boolean)
I am a bit nonplussed that even though this call works, this overload doesn't exist in the COM interop .dll that is created if I instead add a reference to the COM server using Add Reference. The only available call to this method that it says is available is AMethod().
However, this in itself is not what bothers me. What bothers me is that this call works for a while, THEN throws a TargetParameterCountException after a few dozen calls have executed successfully.
I ask thee thus, StackOverflow:
What. The. Hell.
The only thing I can guess at is that the documentation for the COM component states that this method is executed synchronously - so therefore maybe whatever's responsible for throwing that exception is being blocked until some indeterminate point in time? Other than that, I'm completely stumped at this bizarre, and more importantly inconsistent behaviour.
edit #1:
More significant information that I've just remembered - from time to time the call throws an ExecutionEngineException instead. It only took one glance at the documentation to realise that this is VERY BAD. Doing a little bit of digging suggests to me that the late-binding call is causing stack corruption, crashing the entire CLR. Presumably this means that the runtime is shooting down bad calls (with TargetParameterCountException) some of the time and missing them (ExecutionEngineException) others.
edit #2:
Answering David Lively's questions:
The call with zero arguments that's currently in the code has been there for a long time. I haven't been able to get hold of a manual for the third party's COM implementation past two major revisions ago, so it's possible that they've withdrawn that signature from service
There is only one location that this method is called from
This is one desktop app calling another, on the same machine. Nothing fancy
The object is persisted throughout the scope of the user's interaction with the application, so there's never a new one created.
Unfortunately, it seems likely that there is indeed a bug in the implementation, as you suggest. The trouble with this vendor is that, when we report a bug, their response tends to follow the general form: i) deny there's a problem; ii) deny it's their problem; iii) refuse to fix it. These three steps tend to span a frustratingly long period of time.
No, it can't cause stack corruption. IDispatch::Invoke() is used to call the method, the arguments are packaged in an array. The stock implementation of IDispatch certainly would detect the argument mismatch, it uses the type library info to check. But it is conceivable that the COM server author implemented it himself. Imperfectly. It is something a C++ hacker might do, the stock implementation is dreadfully slow. The GC heap getting corrupted is the kind of thing that happens when imperfect code executes.
I haven't played with calling COM objects from VB in quite a while, but I'll take a wild guess:
I would expect an exception to be thrown if you're calling the object with too few or too many arguments, but it appears that's not the case. What is the real signature of the method you're calling?
In some languages and some situations, when you call a method, arguments are placed on the stack. If you place too many arguments, it's possible for the extraneous ones to remain on the stack after the method completes. This should cause lots of other problems, though.
Some possibilities/considerations:
The object is throwing this exception internally. This should be taken up with the author.
You're calling with too many parameters. If, as you said, the overload you're trying to call isn't published in the object's type library, you may actually be calling a different published method with a different signature. I'd REALLY expect a compiler error if this is the case.
Are your later calls taking place in the same part of your code, or is there a different execution branch that might be doing things a bit differently, and causing the error?
Are you running this from a desktop app/script, or a website? If a website, are you receiving a valid, expected response, or does the request hang as if an internal long-running process doesn't complete?
The object may be allocating and not releasing resources, which could cause undefined behavior when those resources are exhausted.
Are you releasing the object between calls, or is it recreated every time?
Also, re: your comments about late binding: the .CreateObject() method of instantiating a COM object is the normal, accepted way to do this. That shouldn't have anything to do with the issue. Based on the exceptions you listed, I'm strongly inclined to believe that there is an internal issue with the object.
Good luck.
OK, basically - false alarm. I've done it wrong - I've copied some code over from somewhere improperly and the thing I'm calling was never supposed to support that overload. What I find interesting is that the component didn't reject that late-bound call out of hand, but did everything it was supposed to do, at least initially.
I'm having a bug in my Objective C program which causes the machine to crash hip deep in some library methods, and it's all library methods down the stack to main (Which I haven't touched from the one XCode gave me). So, I have a bit of a mystery.
The error I'm getting is:
Program received signal: “EXC_BAD_ACCESS”.
Now, I'm sure that this means that somewhere I'm releasing something too many times, or something like that. This is the objective C version of a seg-fault, right?
My question is: Since it's not happening in my own code, is there some clever way of tracking down what I'm double releasing? or is code inspection the best bet?
thanks.
EXC_BAD_ACCESS essentially means that you're trying to access or use a specific chunk of memory in an unexpected way. For example, if you try to send a message to a memory reference that no longer represents a valid object. It's different from a segmentation fault, but related.
See this related SO question for suggestions on debugging over-released objects. NSZombie will work wonders for you. Once you get your hands on Snow Leopard (you're getting it this Friday, right?) use the Zombies instrument to simplify the process, and use the Xcode static analyzer to help you find such errors at compile time.
Also visit: http://www.cocoadev.com/index.pl?DebuggingTechniques and this Apple Tech Note.