runtime library bugs, any recourse?
dhoke
runtime libraries that users are not provided sufficient "stuff" to
rebuild/redistribute, is there any recourse to obtain a fix?
I specifically am using bds2006, but am also interested in a general answer
to the question for any provided product version.
(I have just encountered an allocated buffer overwrite that _might_ be
attributed to something with a name like this,
vcl100.@Controls@TWinControl@DefineProperties$qqrp14Classes@TFiler
although I'm far from actually being convinced it is the culprit, as the
stack provided by the debugger is very sketchy.)
Leo Siefert
>vcl100.@Controls@TWinControl@DefineProperties$qqrp14Classes@TFiler
If that is the actual location of the error then it is in VCL code and
the source is provided at least with most SKUs (probably not with the
explorer versions). If you find the offending code you can make the
correction in the source and simply add the patched source to your
project.
AFAIK, you cannot actually rebuild the actual vcl100 module from
source and redistribute that without breaking the licensing agreement.
If you do want the library code fixed, then you can file a QC report.
If you supply fixed code along with the report, the chances of the
patch being issued promptly are greatly improved (and a sysop - I'm
one - who sees it can point this out to the CodeGear techs).
That being said, my guess is that there is little chance of a patch
for BDS 2006 being issued for anything with a viable workaround since
that is a couple of versions behind the current version and was
released prior to the spin-off of CodeGear and the recent acquisition
by Embarcadero.
Of course you could open a support case on the issue if it is clearly
a bug. That could result in you getting a private informal patch or
some other satisfaction if this is a serious issue for you.
Or maybe your post was more a rant than an actual question... <g>
- Leo
dhoke
"Leo Siefert" <lIHATESP...@senate.michigan.gov> wrote in message
news:o6he74ll3t1rciaok...@4ax.com...
> dhoke wrote:
>
>>vcl100.@Controls@TWinControl@DefineProperties$qqrp14Classes@TFiler
>
> Or maybe your post was more a rant than an actual question... <g>
Not that I feel I am without cause to rant (see further below), but that was
in fact a serious question. (As for the original suggested problem, the
reproduction scenario was slightly involved, but I had it occur three times
in a row, and then couldn't get it to occur in five+ successive attempts.
[No changes were made after the third observed occurrence, through the fifth
failed attempt.] Which, sadly for me, suggests something more insidious,
than a simple vcl/rtl issue.)
I had not thought of the possibility of adding modified source to a specific
project - of course, that would entail adding it to any project that might
be affected. which might mean coming up with some mechanism (a library? -
hoping I could get the linker to resolve in some predictable order) that
could be uniformly applied to all projects in our system, since that would
likely be easier than trying to remember/figure-out what might, or not, be
affected by a particular issue.
As for redistributing breaking licensing, I have tried to rebuild VCL, and
haven't even been able to get it to rebuild (following instructions for
rebuilding vcl posted somewhere for an earlier version of delphi/builder),
so redistributing certainly isn't likely to be an issue. (I think I did
succeed in rebuilding the rtl at some point... If you know how to
successfully rebuild vcl for bds2006, that would be information I'd like to
have, as it would at least help with my development.)
[RANT - plus inquiry]
I will take this opportunity to rant about not being able to both build with
vcl debugging symbols, and use a plug-in memory manager at the same time.
(The memory manager is the one catching the overwrite. But I can't use the
memory manager when I've built to have vcl symbols available, for as far as
I can tell, the source conditionally specifically excludes this possibility
for the debug/symbol vcl/rtl build - what, a user would want to have all
possible debugging aids available at the same time?.)
If I'm incorrect about this, and anyone knows how to use a replacement
memory manager when building _with_ debugging/symbol version of vcl
libraries , please inform. And yes, there was a QC issue I posted that at
least included this, if not focused on it, long ago.
>
> - Leo
Leo Siefert
>Not that I feel I am without cause to rant (see further below),
>but that was in fact a serious question.
I took it as such and gave about as full an answer as I could. But
then sometimes people just want to vent and do not want to deal with
suggestions that may involve some work on their part because they are
too frustrated.
>I had not thought of the possibility of adding modified source
>to a specific project - of course, that would entail adding
>it to any project that might be affected.
Yes. And the VCL code is in Delphi with C++ headers. But playing with
a copy of the suspected file added to your project can be a very
effective way of working around its bugs if you can locate them.
I did not say this was an easy solution, but it can give you a
workaround, as well as the opportunity to more easily determine if the
problem is actually fixed in a later release.
>If you know how to successfully rebuild vcl for bds2006,
>that would be information I'd like to
>have, as it would at least help with my development.)
I think I have heard that that is not possible. I stand to be
corrected if someone else has better info. IIRC, there is some code
that is not provided - asm stuff, I think.
>[RANT - plus inquiry]
Sorry, but I have no help to offer here. I do know that some folks use
the FastMM manager in debug mode, but I don't know if that solves your
problem.
- Leo
dhoke
Per QC50159, I _don't_ think they are using it in debug mode, when their
projects are built to debug with VCL symbols (at least with bds2006.)
If anyone is, I'm very interested in how you've accomplished it. (I suppose
it would be possible adding all of the available VCL sources to a project,
per Leo's suggestion earlier in this thread, and building without specifying
the static/debug VCL version libraries. But I don't consider that a very
viable approach.)
"Leo Siefert" <lIHATESP...@senate.michigan.gov> wrote in message
news:nvve74186p4ksjvrr...@4ax.com...
Eike Petersen
See QC56555.
Regards
Eike
Roddy Pratt
> But playing with a copy of the suspected file
> added to your project can be a very effective
> way of working around its bugs if you can locate them.
Yes, that's a technique I've used often. (Less often with RadStudio,
2007 because the worst bugs (eg variants) are fixed!)
For bugs in the C++ sections or the RTL, you can just create a file
called "overrides.cpp" or similar, and place the fixed versions of
functions in that.
For bugs in the .pas sections, you can add .pas files straight into a
C++ project. Beware that some VCL .pas files can't directly generate
the right HPP headers automatically, so you need to stick with the
original .hpp files.
I can't remember the details of why this happens, but it's something to
do with the trick for extending VCL classes with new properties without
breaking the DFM formats.
- Roddy