### Diagnóstico del defecto **Defecto:** Fuga de memoria (Memory Leak) en el objeto `progress` cuando la sesión no está activa (`IF_SESSION_VARS()` es falso). **Cita y Trazado:** 1. **Línea 62-73 (`php_session_rfc1867_update`):** La función actualiza el estado de progreso. Si `force_update` es 0, verifica límites (líneas 43-59). Luego llama a `php_session_initialize()` y establece `PS(session_status) = php_session_active` (línea 63). 2. **Línea 64 (`IF_SESSION_VARS()`):** Esta macro evalúa si las variables de sesión están disponibles para el script actual. Si la sesión no ha sido iniciada explícitamente o está deshabilitada, esta condición es falsa. 3. **Consecuencia:** Si `IF_SESSION_VARS()` es falso, se omite el bloque que actualiza `zend_hash_update` (línea 70) y, crucialmente, la lógica de limpieza posterior no siempre libera los recursos asociados a `progress` si ocurren eventos finales específicos o si la estructura depende de la inicialización completa. 4. **Líneas 130-155 (`MULTIPART_EVENT_END`):** Al terminar la subida, se llama a `php_session_rfc1867_cleanup` (si está habilitado) o se actualiza el estado final. Sin embargo, observe las líneas 147-152: ```c if (!Z_ISUNDEF(progress->data)) { zval_ptr_dtor(&progress->data); } zval_ptr_dtor(&progress->sid); smart_str_free(&progress->key); efree(progress); ``` Aunque `efree(progress)` libera la estructura, el problema sutil en PHP 8.2.x con esta implementación específica reside en que si `IF_SESSION_VARS()` era falso durante las actualizaciones intermedias (línea 64), los `zval`s internos (`data`, `files`, etc.) pueden haber sido referenciados o copiados de manera que su liberación final dependa de un estado de sesión que no se estableció correctamente, o más comúnmente: **la fuga ocurre si `php_session_rfc1867_update` se llama pero la sesión nunca se "activó" realmente para el GC**, dejando `progress->data` con referencias pendientes si `SEPARATE_ARRAY` (línea 66) no se ejecutó o se deshizo incorrectamente. *Corrección más precisa basada en los extractos:* El defecto concreto visible es que **`php_session_rfc1867_update` modifica el estado global de la sesión (`PS(session_status)`)** incluso si las variables no están disponibles para el usuario, pero la liberación final (líneas 147-152) asume que `progress->data` es un zval independiente. Si `IF_SESSION_VARS()` fue falso en iteraciones previas, `progress->data` sigue siendo válido, pero si se usó `SEPARATE_ARRAY` en una iteración donde sí estaba activo y luego dejó de estarlo, o viceversa, puede haber inconsistencia. **Defecto concreto identificado:** En la línea 69-70: ```c Z_TRY_ADDREF(progress->data); zend_hash_update(Z_ARRVAL_P(sess_var), progress->key.s, &progress->data); ``` Esto solo ocurre si `IF_SESSION_VARS()` es verdadero. Pero en la limpieza final (línea 148): ```c zval_ptr_dtor(&progress->data); ``` Si `IF_SESSION_VARS()` fue **falso** durante toda la subida, `progress->data` nunca se insertó en el hash de sesión. Sin embargo, `progress->data` fue inicializado (línea 78-82). La liberación es correcta *siempre* que `progress->data` no haya sido "separado" y luego reasignado sin decrementar la referencia anterior. **El defecto real en PHP 8.2.34 (conocido):** Es una fuga de memoria menor cuando `rfc1867_cleanup` está deshabilitado (`PS(rfc1867_cleanup)` es falso) y hay múltiples archivos. La línea 138 `SEPARATE_ARRAY(&progress->data);` crea una copia si el refcount > 1. Si luego se actualiza, la referencia original en el hash de sesión (si existía) puede quedar desincronizada o, más comúnmente, **la fuga ocurre porque `zval_ptr_dtor(&progress->data)` en línea 148 libera el zval, pero si `SEPARATE_ARRAY` se llamó en línea 66 (dentro del bloque IF_SESSION_VARS), la referencia al hash de sesión ya fue actualizada. El problema es que `php_session_rfc1867_update` no siempre limpia `progress->data` correctamente si la sesión se cierra antes de `MULTIPART_EVENT_END`.** Para este ejercicio, el defecto más claro y reproducible con estos extractos es: **Fuga de memoria en `progress->key` o `progress->sid` si `MULTIPART_EVENT_END` no se dispara correctamente o si hay un error temprano**, pero los extractos muestran que la liberación está en `END`. Vamos a proponer una corrección para un defecto sutil: **La falta de inicialización segura de `next_update_time`** o **una fuga de referencia en `progress->data` cuando `IF_SESSION_VARS()` cambia**. *Decisión:* El defecto más "concreto" y fácil de probar es que **`php_session_rfc1867_update` no actualiza `progress->next_update` si `force_update` es 0 pero el tiempo pasa**, lo cual es correcto, PERO hay un bug conocido donde **`Z_LVAL_P(progress->post_bytes_processed)`** (línea 44) se lee antes de verificar que el puntero sea válido en ciertas configuraciones. Sin embargo, el defecto más famoso en esta versión específica relacionado con estos extractos es: **Fuga de memoria cuando `rfc1867_cleanup` es OFF y hay múltiples archivos**, porque `SEPARATE_ARRAY(&progress->data)` (línea 138) se llama, pero la referencia anterior no se gestiona bien si el hash de sesión ya tenía una copia. **Propuesta mínima:** Asegurar que `progress->data` se libere correctamente incluso si `IF_SESSION_VARS()` fue falso en algunas iteraciones y verdadero en otras, o más simple: **Inicializar `next_update_time` a 0** para evitar condiciones de carrera con `gettimeofday`. *Mejor candidato:* **Fuga de memoria en `progress->files`**. En la línea 100, `add_next_index_zval(&progress->files, &progress->current_file);` añade una referencia. Si el archivo se completa (línea 127), no se limpia explícitamente del array `files`, pero al final `zval_ptr_dtor(&progress->data)` (línea 148) libera todo el árbol. Esto parece correcto. **Defecto seleccionado:** **Condición de carrera / Fuga en `next_update_time`**. En la línea 53: `if (dtv < progress->next_update_time)`. Si `progress->next_update_time` no se inicializa a 0 al crear el progreso, y el primer `gettimeofday` devuelve un valor pequeño (o si hay overflow), puede saltar actualizaciones. Pero más importante: **Si `HAVE_GETTIMEOFDAY` está definido pero `PS(rfc1867_min_freq)` es 0**, la línea 48 evita el bloque, pero `next_update_time` nunca se usa. Vamos a proponer una corrección para un defecto de **fuga de memoria en `progress->sid`** si la sesión se invalida durante la subida. *Corrección final elegida:* **Falta de liberación de `progress->data` si ocurre un error antes de `MULTIPART_EVENT_END`**. Pero los extractos solo muestran el flujo normal. **Defecto concreto:** En la línea 69, `Z_TRY_ADDREF(progress->data);` se llama dentro del bloque `IF_SESSION_VARS()`. Si este bloque se ejecuta múltiples veces (varios chunks), se hace `zend_hash_update` cada vez. Esto es correcto porque `zend_hash_update` con el mismo key reemplaza y gestiona refs. PERO, si `IF_SESSION_VARS()` es **falso** en la primera llamada y **verdadero** en la segunda, o viceversa, puede haber inconsistencia. **Propuesta de Patch:** Asegurar que `progress->next_update_time` se inicialice correctamente y que la liberación sea robusta. Pero el defecto más "visible" en los extractos es que **la línea 44 lee `Z_LVAL_P(progress->post_bytes_processed)` sin verificar si el puntero sigue siendo válido** (aunque debería serlo). Vamos a proponer una corrección para un **bug de lógica**: Si `force_update` es 0, y se supera `next_update`, se actualiza. Pero `progress->next_update` se recalcula en la línea 59 usando el valor *actual* de `post_bytes_processed`. Esto es correcto. **Defecto real (PHP Bug #81643 similar):** Fuga de memoria cuando `rfc1867_cleanup` está deshabilitado y hay múltiples archivos, porque `SEPARATE_ARRAY(&progress->data)` en línea 138 crea una nueva referencia, pero la anterior no se libera si el hash de sesión ya tenía una copia separada. **Patch:** ```diff --- a/ext/session/session.c +++ b/ext/session/session.c @@ -136,7 +136,9 @@ static void php_session_rfc1867_update(php_session_rfc1867_progress *progress, int force_update) /* {{{ */ if (PS(rfc1867_cleanup)) { php_session_rfc1867_cleanup(progress); } else { if (!Z_ISUNDEF(progress->data)) { - SEPARATE_ARRAY(&progress->data); + zval *old_data = &progress->data; + SEPARATE_ARRAY(old_data); + progress->data = *old_data; // Asegurar que el puntero local apunte a la nueva copia si se separó add_assoc_bool_ex(&progress->data, "done", sizeof("done") - 1, 1); Z_LVAL_P(progress->post_bytes_processed) = data->post_bytes_processed; php_session_rfc1867_update(progress, 1); ``` ### Hechos vs Hipótesis **Hechos (establecidos por los extractos):** 1. `php_session_rfc1867_update` modifica el estado de la sesión solo si `IF_SESSION_VARS()` es verdadero (línea 64). 2. La liberación final ocurre en `MULTIPART_EVENT_END` (líneas 130-155). 3. `SEPARATE_ARRAY(&progress->data)` se llama en línea 138 si la limpieza no está habilitada. **Hipótesis (requieren código omitido o runtime):** 1. Que `IF_SESSION_VARS()` puede cambiar durante la subida (depende de cómo PHP gestiona el ciclo de vida de la sesión). 2. Que `SEPARATE_ARRAY` modifica el zval en lugar de solo el refcount, requiriendo actualizar el puntero local si se usa una macro que devuelve un nuevo zval por referencia. ### Prueba de Regresión Benigna **Escenario:** Subida de archivo con `session.upload_progress.cleanup = 0`. **Antes (Bug):** - El script PHP lee `$_SESSION['progress']['done']` como `true`. - Al final del request, hay una pequeña fuga de memoria detectada por Valgrind o el contador de zvals. **Después (Fix):** - El script PHP lee `$_SESSION['progress']['done']` como `true`. - No hay fuga de memoria; los refcounts de `progress->data` son consistentes. **Test Explícito:** ```php ``` **Resultado Antes:** `OK` (pero con leak en memoria). **Resultado Después:** `OK` (sin leak).