@Tony
The problem here is that Josh sent incompatible parameters to AllocVecTags() ie. AVT_TYPE with MEMF_ANY. He's already checking for return but in this case AllocVecTags() allocated something that is not usable, instead it would have been better if AllocVecTags() returned NULL.
AllocVecTags
Re: AllocVecTags
AmigaOne X1000 running AOS 4 beta
AmigaOne XE/G4
Amiga 1200/PPC 603e + BVision PPC
AmigaOne XE/G4
Amiga 1200/PPC 603e + BVision PPC
- Thomas Frieden
- AmigaOS Core Developer
- Posts: 147
- Joined: Fri Dec 10, 2010 3:21 pm
Re: AllocVecTags
When you write code, it is your responsibility as a developer to at least check the documentation of functions that you are using and understanding what they do. In this case, changing from AllocVec to AllocVecTags, you simply did not check the documentation of the function, otherwise, you would have known that the value was illegal.JosDuchIt wrote:I can't but rephrase that i am rather disappointed that "the SDK does not provide more in detecting wong input to functions with a limited number of acceptable parameter values" If the easiest solution to this means that such library functions should be rewritten to fail more gracefully and provide help info, i am all for it.
If all this is unrealistic, so be it.
If every function would validate it's input completely, it would be far too slow. Therefore, the system relies on some validation done by the developer. It is not feasible to have a function always validate it's whole input since of all the millions of cases the function is called, the input is always right except for one or two cases.
Finally, if you are interested in fixing this problem (yes, it MIGHT be a bug, I don't know), I would appreciate if you could give constructive feedback. For example, the "unhelpful crash" is actually even more unhelpful if you keep the details to yourself. If you would share the crash, I could actually check if there IS a problem with the function and fix it.
- Hans-Joerg Frieden
- AmigaOS Core Developer
- Posts: 223
- Joined: Wed Dec 08, 2010 3:52 pm
Re: AllocVecTags
Not that there was any way to check anyway, even on the old system if you wrote "AllocVec(size, 42)", you'd get everything but the answer to the universal question. It's a general problem with tag items, but even with normal parameters you would run into this problem.ssolie wrote:That is impossible because tag IDs and tag data are all uint32 types. There are no types for the compiler to check.JosDuchIt wrote:I am rather disappointed thet the compiler does not give any warning, error or undefined reference in this case.
As everybody pointed out already, it pays to check the documentation
NOTICE: If you want to contact me, use E-Mail. I cannot be contacted via the forum/private messages anymore
Re: AllocVecTags
@Hans-Joerg & Thomas
I agree that it's developer responsibility to read, understand and conform to the API documentation.
But on the other hand it would make sense if AllocVecTags() doesn't allow impossible combinations, returning NULL instead of an allocated object that is known to be crashing the next instruction.
I didn't tried myself the code above but my understanding of Josh problem is that AllocVecTags() was returning a value different from NULL but unusable, in such case then it's a problem in AllocVecTags(), if instead it's AllocVecTags() that is crashing because the calling programmer didn't conform to the API then it's mixed because it's the calling programmer's fault (if you'd asked my I would also have deemed a part of the responsibility on AllectVecTags() for not being error tolerant proof, but it's only IMHO .
I agree that it's developer responsibility to read, understand and conform to the API documentation.
But on the other hand it would make sense if AllocVecTags() doesn't allow impossible combinations, returning NULL instead of an allocated object that is known to be crashing the next instruction.
I didn't tried myself the code above but my understanding of Josh problem is that AllocVecTags() was returning a value different from NULL but unusable, in such case then it's a problem in AllocVecTags(), if instead it's AllocVecTags() that is crashing because the calling programmer didn't conform to the API then it's mixed because it's the calling programmer's fault (if you'd asked my I would also have deemed a part of the responsibility on AllectVecTags() for not being error tolerant proof, but it's only IMHO .
AmigaOne X1000 running AOS 4 beta
AmigaOne XE/G4
Amiga 1200/PPC 603e + BVision PPC
AmigaOne XE/G4
Amiga 1200/PPC 603e + BVision PPC
- Thomas Frieden
- AmigaOS Core Developer
- Posts: 147
- Joined: Fri Dec 10, 2010 3:21 pm
Re: AllocVecTags
See my post again. As I said, it shouldn't crash, so I would like to see the crash it produces, or maybe a description of what is wrong. For example, no one mentioned that it will return a value that is nonsense.abalaban wrote: But on the other hand it would make sense if AllocVecTags() doesn't allow impossible combinations, returning NULL instead of an allocated object that is known to be crashing the next instruction.
In general, "It doesn't work" or "it crashes" is bound to be ignored. A description of an error is something else, and can be fixed.
I still stand by my original assessment, though: It is impossible and impractical for functions to fully validate their input for correctness.
Re: AllocVecTags
In general, "It doesn't work" or "it crashes" is bound to be ignored. A description of an error is something else, and can be fixed.
I was never implying that the function was buggy. Being accustomed to more userfriendly languages than C and ignoring what the compiler checks (types) and what the functions can or cannot check taking speed into account, i just made an uniformed statement.
I cannot report more about the crash than that it did freeze everything, no debugging output whatsoever. To my knowledge ANY_MEM was not defined in the system, and indeed i should have checked again (i really did but then left an uncorrected line and took ut ip a week later.
Checking the function again in the context of a large source file and seeing the same crash again will not give any more info i think. Or can it ? I am not able to give more info anyway right now
Re: AllocVecTags
It is a good idea to have the serial port connected via null modem cable to another computer to capture any output. It can also help to use the so-called debug kernel which is named kernel.debug. Finally, you can adjust the amount of debug output using the kdebug command.JosDuchIt wrote:I cannot report more about the crash than that it did freeze everything, no debugging output whatsoever...
It is easy to lose a week of time when the system "freezes" but that is actually very rare. There is almost always something output via the serial port which can help save you that week of time.
It is my hope these types of tips will be made available on the official AmigaOS developer wiki which is next on my list of projects.
In any case, without such debug output Thomas can do nothing for you. What may help is if you provided the smallest compilable code fragment you can which reproduces the issue. That way others can at least try the test with a properly setup serial port output and maybe provide Thomas with something to work from.
ExecSG Team Lead