En qué versión de Delphi se ha corregido cierto problema en Vcl.OleCtrls.pas

[dec]

Hola,

Por cierto JOSEPE, ¿podrías poner aquí también la implementación de "GetIUnknownProp" en Delphi 10? Está al lado de la de "GetIDispatchProp" y ambos parecen estar implicados en el problema.

¡Gracias!

[[Al González]]

Hola David.

El artículo que enlazas contiene esto en la cabecera:

Empezado por Marc Durdin

Update 21 Sep 2015: This bug has been fixed in Delphi 10 Seattle.

Creo que podrías asumir que la falla está presente en todas las versiones anteriores. Aunque da más confianza cuando algún documento oficial del fabricante lo confirma (al menos esta fecha de corrección nos permite inferirlo).

Ahora bien, revisando su propuesta y la solución que Embarcadero implementó, te diría que ambas son equivalentes en resultado. Sin embargo, no hace falta sabiduría para darnos cuenta de que la segunda opción consume más ciclos de CPU, mientras que la primera es parca pero más eficiente. En la solución de Embarcadero, la sentencia "Result := IDispatch(Temp.VDispatch)" obtiene una copia de la interfaz contenida en Temp.VDispatch e incrementa en uno su contador de referencias. Luego la sentencia "IDispatch(Temp.VDispatch) := nil" disminuye en 1 ese mismo contador, lo cual, dada la sentencia anterior, se vuelve necesario. En cambio, en la solución que Marc Durdin propone, "Pointer(Result) := Temp.VDispatch" obtiene una copia de la interfaz sin incrementar su contador de referencias, por lo tanto sin necesidad de hacer un decremento explícito.

La solución del artículo es más elegante y eficiente. Según los enlaces del autor, al parecer lo tomó de aquí. Mientras que el programador que escribió la corrección en Delphi Seattle parece haberse limitado a añadir una línea de parche, sin atender el problema de fondo. (La única justificación, aunque ligera, que podríamos darle a añadir esa línea de más, es que estuviera previendo que Embarcadero revisara el manejo de la estructura de los variants por parte del compilador).

La causa del problema reside en que la estructura interna de un valor Variant —el tipo TVarData— es, valga la redundancia, un registro con parte variante. El compilador de Delphi no admite que en la parte variante de un record aparezca declarado un campo cuyo tipo lo haga emplear un contador de referencias, como es el caso de las cadenas de caracteres, las interfaces y algunos otros. Así que, para salvar esa limitante —que es bastante razonable y justificada—, algunos campos del registro variante TVarData fueron declarados como punteros genéricos:

Código Delphi [-]
  TVarData = packed record
    ...
                      case Integer of
                        varDispatch: (VDispatch: Pointer);
                        ...
                        varUnknown:  (VUnknown: Pointer);
                        ...
                        varString:   (VString: Pointer);
                        ...
                        varUString:  (VUString: Pointer);
    ...

El problema con estos es que, al quedar el registro fuera de ámbito (la variable local Temp queda fuera de ámbito cuando GetIDispatchProp llega a su end), nada se encarga de revisarlos para ver si contienen algo que haga falta ser liberado. Muy al contrario de si VDispatch fuera un campo normal declarado de tipo IDispatch en lugar de Pointer.

Así que al extraer valores que usan contadores de referencias de variables, parámetros, propiedades o campos explícitamente declarados con un tipo "comodín", como el Pointer, es menester recordar que ahí hay algo que habrá de ser descontado tras la extracción (solución de Embarcadero), o bien, evitar que aumente el contador utilizando un molde de tipo sobre el receptor (solución del artículo). El truco con esta opción es que el contador se mantiene intacto, y transfiere la responsabilidad de reducirlo al receptor del valor. En el ejemplo que nos ocupa, GetProperty pone en Temp.VDispatch una interfaz a la cual le incrementa en uno su contador de referencias, y la responsabilidad de restar ese 1 queda en el llamador de GetIDispatchProp (puesto que a él le pertenece Result). El intermediario GetIDispatchProp ni se entera de que está contrabandeando una interfaz.

Espero esta pequeña contribución dé algún valor al tema.

Al González.

P.D. David: Te confirmo que en Delphi XE7 Update 1 el código de los métodos mencionados aún presentaban esa falla:

function TOleControl.GetIDispatchProp(Index: Integer): IDispatch;
var
  Temp: TVarData;
begin
  GetProperty(Index, Temp);
  Result := IDispatch(Temp.VDispatch);
end;

...

function TOleControl.GetIUnknownProp(Index: Integer): IUnknown;
var
  Temp: TVarData;
begin
  GetProperty(Index, Temp);
  Result := IUnknown(Temp.VUnknown);
end;

[dec]

Hola a todos,

Qué buena respuesta Al, me alegro mucho de no haber leído que el problema se ha resuelto en Delphi 10, con tal de haber podido leer tu respuesta. Muchas gracias, de verdad, puesto que además uno dudaba de qué solución emplear (la del artículo o la de Delphi 10) y ahora parece claro cuál puede ser mejor.

El caso es que debe haber mucha confusión en todo esto, seguramente, porque algunos que nos llamamos a nosotros mismos programadores, en realidad pecamos de no saber de la misa la media de muchísimas cosas, como queda claro en mi caso, sin ir más lejos, con este problema conque me he topado.

No sé si me excusará algo el hecho de que, buscando por internet sobre los problemas de la "ocupación" de memoria del control "TWebBrowser", algún que otro bien considerado programador (del que jamás dudaría de su capacidad) no llegó tampoco a acertar con una solución. Pero seguro que no tuvo tiempo.

El caso es que de lo que dices entiendo que este problema puede estar también en otro tipo de controles, no sólo en el "TWebBrowser", y, en verdad puede ser un problema bastante curioso, puesto que este control en concreto (a fuerza de crear y destruir unos cuantos de ellos) puede terminar provocando un grave error.

Yo no había notado el problema hasta mi proyecto App Builder, puesto que este hace un uso intensivo (demasiado intensivo, en mi opinión, habría que tratar de reducirlo al máximo) del control "TWebBrowser". Un usuario del programa me reportó el problema, que, yo también tenía, sin llegar nunca a un "out of memory" como en su caso.

Ahora parece que el problema está solucionado, aunque, como vemos, hay que tocar algunas cosas como los componentes de "EmbeddedWB" (que yo uso en mi programa) y hasta la VCL... que es la primera vez que toco en todos estos años trabajando con Delphi. Jamás había tenido que tocar nada de la VCL hasta hoy.

En fin, cualquier otro comentario será bienvenido, pero, vuelvo a darte las gracias por tu estupenda respuesta Al.

[[Al González]]

Empezado por dec

Jamás había tenido que tocar nada de la VCL hasta hoy.

Es preferible que no lo hagas. Yo he tenido la inmensa fortuna de conseguir darle la vuelta a este tipo de problemas casi siempre que me he topado con alguno, sin tener que modificar código fuente ajeno. Más importante aún si tal código no es libre e implica volver a hacer lo mismo con otras versiones de Delphi.

Eché un vistazo a TOleControl y su método GetProperty:

Código Delphi [-]
procedure TOleControl.GetProperty(Index: Integer; var Value: TVarData);
var
  Status: HResult;
  ExcepInfo: TExcepInfo;
begin
  CreateControl;
  Value.VType := varEmpty;
  Status := FControlDispatch.Invoke(Index, GUID_NULL, 0,
    DISPATCH_PROPERTYGET, DispParams, @Value, @ExcepInfo, nil);
  if Status <> 0 then DispatchInvokeError(Status, ExcepInfo);
end;

Creo que hay oportunidad de sustituir el valor del campo FControlDispatch ahí visto, que es una interfaz, por una segunda interfaz que envuelva a la primera, pero copiando desde el nuevo método Invoke el valor devuelto por el viejo Invoke en el seudo-variante Value (cuando éste sea una interfaz) hacia una variable que posteriormente usemos para reducir el contador de forma controlada, en tiempo y forma. Evitando así la inundación y potencial desborde de la memoria.

Ahora no dispongo de mucho tiempo, pero en estos días podemos desarrollarlo aquí mismo entre los compañeros interesados en el tema. Podría ser un buen ejercicio colectivo.

Un saludo.

Al.

[Casimiro Notevi]

Empezado por Al González

Ahora no dispongo de mucho tiempo, pero en estos días podemos desarrollarlo aquí mismo entre los compañeros interesados en el tema. Podría ser un buen ejercicio colectivo.
Un saludo.
Al.

Sería estupendo, aunque la mayoría solamente podamos participar viendo trabajar a los verdaderos maestros

[dec]

Hola a todos,

Tampoco a mí me hace mucha gracias tocar la VCL, pero, digo un poco lo que Casimiro: buscando una respuesta al problema la encontré, dicho de otra forma: jamás hubiese podido idear la solución al problema en cuestión. Afortunadamente existís los que sabéis más que nosotros. La solución que propones implica poder usar nuestro propio "OleControl" modificado e "interpuesto", si no me equivoco, de modo que no hiciese falta tocar la VCL. Yo me comprometo a hacer las pruebas que sean menester y poco más, me temo.

Ciertamente la VCL no es libre, pero, en todo caso, creo que se trata de algo más que comprensible, si no existe otra forma de hacerlo. Al fin y al cabo estamos tratando de solucionar un problema que puede causar un error grave de desbordamiento de memoria. Tal vez no se pueda/deba modificar la VCL, pero, a falta de otra solución, ¿quién estaría dispuesto a continuar con el problema estando ahí disponible una posible solución? Si es cierto que se trata de un bug de Delphi, han tenido desde 1999 para solucionarlo.

¡Gracias de nuevo Al y gracias a todos!

[JOSEPE]

Aunque creo que ya no es necesario, igual pongo el metodoGetIUnknownProp incluido en Delpi 10 Seattle .
Saludos.

Código Delphi [-]
function TOleControl.GetIUnknownProp(Index: Integer): IUnknown;
var
  Temp: TVarData;
begin
  GetProperty(Index, Temp);
  Result := IUnknown(Temp.VUnknown);
  IUnknown(Temp.VUnknown) := nil;
end;