Código basura de GCC?

lweb20 · 1 Marzo 2013, 01:12 AM

EI: del Cache de Google:
cache:http://foro.elhacker.net/programacion_cc/codigo_basura_de_gcc-t384404.0.html

Hola a todos. A ver a ver cómo empezar...

Antes que nada, me disculpo de la forma cómo hablo ya que no soy muy bueno escribiendo en foros (sí en blogs, por ejemplo el mío). No quiero ofender a nadie.

Bueno, estoy programando un sistema operativo de 32 bits como hobby (No soy un novato más). Estuve como 5 meses leyendo y leyendo (claro, aparte del tiempo que estuve estudiando por mi cuenta asm de 16 bits - no mucho pero me sirvió para hacer un micro-so

), haciendo pruebas y encontré un manual de paso a paso cómo iniciar un kernel. Bueno ya tengo mi kernel que inicia el GDT, IDT, el teclado, la disquetera, y algunas otras cosas (no menos importantes).

La cosa es que estuve programando y re-programando (volviendo a programar para corregir errores y mejorarlos) algunos drivers básicos (ya saben) y como tenía tanto código cada compilada se comenzaba a demorar más y más en compilar (y nada en ejecutar

) y se me ocurrió cargar un archivo en la memoria y luego ejecutarlo (call).

Como siempre estuve haciendo pruebas tras pruebas, investigando como loco y cuando me puse a descansar un rato se me vino la solución a la cabeza y listo! pude ejecutar un archivo ensamblado con nasm en mi kernel usando una interrupción del IDT (int 0x80 - mostrar un texto en la pantalla) y todo funciona ok.

Ahora quise que un programa compilado con un lenguaje de alto nivel (C) se pudiera ejecutar en mi kernel y después de 2 días pude lograrlo.. A medias... Lo que pasa es que me ejecuta el código pero cuando termina la ejecución se genera un page fault (excepción) y estuve revisando el por qué, adjunto el código del archivo de C, el linker script, el batch y las imágenes que tengo:

LINKER SCRIPT (los comentarios que ves los agregué al postear)

Código [Seleccionar]

ENTRY("_inicio")
SECTIONS
{
    . = 0x10000; // Aquí es donde ubica el kernel al programa
//lo demás no lo entiendo (no voy a mentir) aunque me solucionó un problema anterior (googleando lo encontré)
    .text :
    {
        code = .;
        *(.text)
        text_end = .;
    }
    .rodata :
    {
        rodata = rodata_end;
        *(.rodata)
        rodata_end  = .;     
    }   
    .rdata :
    {
        rdata = rdata_end;
        *(.rodata)
        rdata_end  = .;     
    }
    .data :
    {
        data = data_end;
        *(.data)
        data_end = .;
    }
    .bss : 
    {
        bss = bss_end;
        *(.bss)
        bss_end = .;
    }
    end = .;
            /DISCARD/ :{
                *(.note*)
                *(.indent)
                *(.comment)
                *(.stab)
                *(.stabstr)
        }
}

PROGRAMA EN C (GCC)

Código [Seleccionar]

void inicio(){
char* imprimir = "Hola mundo desde GCC (Intel Syntax, programa.exe) v2!";
asm(
"xor eax, eax\n" // función 0
"mov ebx, %0\n" // cadena
"int 0x80\n" // llama a la interrupción del kernel
:
: "m"(imprimir)
);
return;
}

BATCH

// Yo mismo lo hice xD

Código [Seleccionar]

:X
cls

gcc -march=i686 -std=gnu99 -ffreestanding -c test.c -masm=intel // aquí hay un problema a mi parecer
ld -o test -Tlink.ld test.o //creo el archivo PE
objcopy -S -O binary test ..\programa.exe //genero un archivo binario en base al archivo PE
pause
goto X

Bueno acá van las imágenes.

1. Aquí veo un código "basura" el cual me parece que mi kernel no lo entiende o no sé que sea :S

CÓDIGO OBJETO OBTENIDO POR GCC. Lo seleccionado es lo que me parece que es el problema.

2. Aquí se repite el código. Extrañamente se fue al final del archivo binario

Cuando borro el código seleccionado manualmente en el binario se ejecuta mi programa normalmente.

Por cierto mis primeros lenguajes de programación entre comillas fueron HTML, javascript (tenía 9 años xD), después a los 13 aprendí VB.NET que es el lenguaje que siento que soy muy bueno (llevo años..) y a los 17 (masomenos) aprendí C++ (me adapté al C luego :p) y asm tuve que estudiarlo a la fuerza (obviamente no soy tan bueno pero me defiendo). Todo esto fue por mi cuenta.

No sé si alguien podría ayudarme o darme una pista para poder entender qué cosa es ese código que sobra y cómo podría eliminarlo o no ejecutarlo.

POSDATA: Mi kernel ejecuta desde el indice 0 del archivo (no ejecuta PE ni ELF, sólo binarios)

Gracias por haber leído tal discurso

Eternal Idol · 1 Marzo 2013, 18:09 PM

Usando dumpbin del VC++ en test.o:

Dump of file test.o

File Type: COFF OBJECT

FILE HEADER VALUES
14C machine (x86)
5 number of sections
0 time date stamp Thu Jan 01 01:00:00 1970
178 file pointer to symbol table
E number of symbols
0 size of optional header
104 characteristics
Line numbers stripped
32 bit word machine

SECTION HEADER #1
.text name
0 physical address
0 virtual address
18 size of raw data
DC file pointer to raw data (000000DC to 000000F3)
164 file pointer to relocation table
0 file pointer to line numbers
1 number of relocations
0 number of line numbers
60300020 flags
Code
4 byte align
Execute Read

RAW DATA #1
00000000: 55 89 E5 83 EC 10 C7 45 FC 00 00 00 00 31 C0 8B U.å.ì.ÇEü....1À.
00000010: 5D FC CD 80 C9 C3 90 90 ]üÍ.ÉÃ..

RELOCATIONS #1
Symbol Symbol
Offset Type Applied To Index Name
-------- ---------------- ----------------- -------- ------
00000009 DIR32 00000000 A .rdata

SECTION HEADER #2
.data name
0 physical address
0 virtual address
0 size of raw data
0 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0300040 flags
Initialized Data
4 byte align
Read Write

SECTION HEADER #3
.bss name
0 physical address
0 virtual address
0 size of raw data
0 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0300080 flags
Uninitialized Data
4 byte align
Read Write

SECTION HEADER #4
.rdata name
0 physical address
0 virtual address
38 size of raw data
F4 file pointer to raw data (000000F4 to 0000012B)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40300040 flags
Initialized Data
4 byte align
Read Only

RAW DATA #4
00000000: 48 6F 6C 61 20 6D 75 6E 64 6F 20 64 65 73 64 65 Hola mundo desde
00000010: 20 47 43 43 20 28 49 6E 74 65 6C 20 53 79 6E 74 GCC (Intel Synt
00000020: 61 78 2C 20 70 72 6F 67 72 61 6D 61 2E 65 78 65 ax, programa.exe
00000030: 29 20 76 32 21 00 00 00 ) v2!...

SECTION HEADER #5
/4 name (.eh_frame)
0 physical address
0 virtual address
38 size of raw data
12C file pointer to raw data (0000012C to 00000163)
16E file pointer to relocation table
0 file pointer to line numbers
1 number of relocations
0 number of line numbers
40300040 flags
Initialized Data
4 byte align
Read Only

RAW DATA #5
00000000: 14 00 00 00 00 00 00 00 01 7A 52 00 01 7C 08 01 .........zR..|..
00000010: 1B 0C 04 04 88 01 00 00 1C 00 00 00 1C 00 00 00 ................
00000020: 04 00 00 00 16 00 00 00 00 41 0E 08 85 02 42 0D .........A....B.
00000030: 05 52 C5 0C 04 04 00 00 .RÅ.....

RELOCATIONS #5
Symbol Symbol
Offset Type Applied To Index Name
-------- ---------------- ----------------- -------- ------
00000020 REL32 00000004 4 .text

COFF SYMBOL TABLE
000 00000000 DEBUG notype Filename | .file
test.c
002 00000000 SECT1 notype () External | _inicio
tag index 00000000 size 00000000 lines 00000000 next function 00000000
004 00000000 SECT1 notype Static | .text
Section length 16, #relocs 1, #linenums 0, checksum 0
006 00000000 SECT2 notype Static | .data
Section length 0, #relocs 0, #linenums 0, checksum 0
008 00000000 SECT3 notype Static | .bss
Section length 0, #relocs 0, #linenums 0, checksum 0
00A 00000000 SECT4 notype Static | .rdata
Section length 36, #relocs 0, #linenums 0, checksum 0
00C 00000000 SECT5 notype Static | .eh_frame
Section length 38, #relocs 1, #linenums 0, checksum 0

String Table Size = 0x18 bytes

Summary

0 .bss
0 .data
38 .eh_frame
38 .rdata
18 .text

Idem en el test:

Dump of file test

PE signature found

File Type: EXECUTABLE IMAGE

FILE HEADER VALUES
14C machine (x86)
3 number of sections
5130DE02 time date stamp Fri Mar 01 17:57:38 2013
A00 file pointer to symbol table
27 number of symbols
E0 size of optional header
307 characteristics
Relocations stripped
Executable
Line numbers stripped
32 bit word machine
Debug information stripped

OPTIONAL HEADER VALUES
10B magic # (PE32)
2.22 linker version
200 size of code
400 size of initialized data
0 size of uninitialized data
FFC10000 entry point (100010000)
FFC10000 base of code
0 base of data
400000 image base (00400000 to 100011FFF)
1000 section alignment
200 file alignment
4.00 operating system version
1.00 image version
4.00 subsystem version
0 Win32 version
FFC12000 size of image
200 size of headers
F21E checksum
3 subsystem (Windows CUI)
0 DLL characteristics
200000 size of stack reserve
1000 size of stack commit
100000 size of heap reserve
1000 size of heap commit
0 loader flags
10 number of directories
0 [ 0] RVA [size] of Export Directory
0 [ 0] RVA [size] of Import Directory
0 [ 0] RVA [size] of Resource Directory
0 [ 0] RVA [size] of Exception Directory
0 [ 0] RVA [size] of Certificates Directory
0 [ 0] RVA [size] of Base Relocation Directory
0 [ 0] RVA [size] of Debug Directory
0 [ 0] RVA [size] of Architecture Directory
0 [ 0] RVA [size] of Global Pointer Directory
0 [ 0] RVA [size] of Thread Storage Directory
0 [ 0] RVA [size] of Load Configuration Directory
0 [ 0] RVA [size] of Bound Import Directory
0 [ 0] RVA [size] of Import Address Table Directory
0 [ 0] RVA [size] of Delay Import Directory
0 [ 0] RVA [size] of COM Descriptor Directory
0 [ 0] RVA [size] of Reserved Directory

SECTION HEADER #1
.text name
18 virtual size
FFC10000 virtual address (100010000 to 100010017)
200 size of raw data
200 file pointer to raw data (00000200 to 000003FF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
60300020 flags
Code
RESERVED - UNKNOWN
RESERVED - UNKNOWN
Execute Read

RAW DATA #1
100010000: 55 89 E5 83 EC 10 C7 45 FC 18 00 01 00 31 C0 8B U.å.ì.ÇEü....1À.
100010010: 5D FC CD 80 C9 C3 90 90 ]üÍ.ÉÃ..

SECTION HEADER #2
.rdata name
38 virtual size
FFC10018 virtual address (100010018 to 10001004F)
200 size of raw data
418 file pointer to raw data (00000418 to 00000617)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40300040 flags
Initialized Data
RESERVED - UNKNOWN
RESERVED - UNKNOWN
Read Only

RAW DATA #2
100010018: 48 6F 6C 61 20 6D 75 6E 64 6F 20 64 65 73 64 65 Hola mundo desde
100010028: 20 47 43 43 20 28 49 6E 74 65 6C 20 53 79 6E 74 GCC (Intel Synt
100010038: 61 78 2C 20 70 72 6F 67 72 61 6D 61 2E 65 78 65 ax, programa.exe
100010048: 29 20 76 32 21 00 00 00 ) v2!...

SECTION HEADER #3
.eh_fram name
38 virtual size
FFC11000 virtual address (100011000 to 100011037)
200 size of raw data
800 file pointer to raw data (00000800 to 000009FF)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
40300040 flags
Initialized Data
RESERVED - UNKNOWN
RESERVED - UNKNOWN
Read Only

RAW DATA #3
100011000: 14 00 00 00 00 00 00 00 01 7A 52 00 01 7C 08 01 .........zR..|..
100011010: 1B 0C 04 04 88 01 00 00 1C 00 00 00 1C 00 00 00 ................
100011020: E0 EF FF FF 16 00 00 00 00 41 0E 08 85 02 42 0D àïÿÿ.....A....B.
100011030: 05 52 C5 0C 04 04 00 00 .RÅ.....

COFF SYMBOL TABLE
000 0000000A DEBUG notype Filename | .file
test.c
002 00000000 SECT1 notype () External | _inicio
tag index 00000000 size 00000000 lines 00000000 next function 00000000
004 00000000 SECT1 notype Static | .text
Section length 16, #relocs 1, #linenums 0, checksum 0
006 00000000 SECT2 notype Static | .rdata
Section length 36, #relocs 0, #linenums 0, checksum 0
008 00000000 SECT3 notype Static | .eh_frame
Section length 38, #relocs 1, #linenums 0, checksum 0
00A 00000000 SECT2 notype External | rdata
00B 00000000 SECT2 notype External | rdata_end
00C 00000000 ABS notype External | __dll_characteristics__
00D 00001000 ABS notype External | __size_of_stack_commit__
00E 00200000 ABS notype External | __size_of_stack_reserve__
00F 00000004 ABS notype External | __major_subsystem_version__
010 00000018 SECT1 notype External | text_end
011 00001000 ABS notype External | __size_of_heap_commit__
012 00000000 ABS notype External | __dll__
013 00000000 ABS notype External | __minor_os_version__
014 00400000 ABS notype External | __image_base__
015 00001000 ABS notype External | __section_alignment__
016 00011038 ABS notype External | end
017 00000038 SECT3 notype External | bss_end
018 00000038 SECT3 notype External | bss
019 00000200 ABS notype External | __file_alignment__
01A 00000038 SECT3 notype External | data
01B 00000004 ABS notype External | __major_os_version__
01C 00100000 ABS notype External | __size_of_heap_reserve__
01D 00400000 ABS notype External | ___ImageBase
01E 00000003 ABS notype External | __subsystem__
01F 00000000 SECT2 notype External | rodata_end
020 00000001 ABS notype External | __major_image_version__
021 00000000 ABS notype External | __loader_flags__
022 00000000 SECT1 notype External | code
023 00000000 ABS notype External | __minor_subsystem_version__
024 00000000 ABS notype External | __minor_image_version__
025 00000000 SECT2 notype External | rodata
026 00000038 SECT3 notype External | data_end

String Table Size = 0x195 bytes

Summary

1000 .eh_fram
1000 .rdata
1000 .text

De cualquier manera no se como eso pueda afectar, antes esta el codigo (y la sección .rdata tambien) y este termina con un ret por lo cual deberia devolver el control al Kernel ... no me gusta adivinar y sin tener el resto del sistema es lo unico que podemos hacer. ¿Seguro ves el mensaje en pantalla antes de la excepcion? ¿Seguro cargaste el programa.exe en 0x10000, no? Si _inicio no es 0x10000 es facil que se genere una excepcion al acceder a cualquier parte ... la cadena tiene que estar en la direccion de memoria 0x10018 para que funcione ...

_inicio:
00000000: 55 push ebp
00000001: 89 E5 mov ebp,esp
00000003: 83 EC 10 sub esp,10h
00000006: C7 45 FC 00 00 00 mov dword ptr [ebp-4],offset .rdata
00
0000000D: 31 C0 xor eax,eax
0000000F: 8B 5D FC mov ebx,dword ptr [ebp-4]
00000012: CD 80 int 80h
00000014: C9 leave
00000015: C3 ret
00000016: 90 nop
00000017: 90 nop

PD. Esta no es una pregunta sobre C/C++ sino sobre un compilador en particular, nadie mejor que el desarrollador del mismo para responderte con precision.

lweb20 · 3 Marzo 2013, 18:01 PM

Sí, el programa se carga en esa dirección de memoria. Uso memmove para mover los datos a esa dirección de memoria. Me muestra el mensaje, y también me parece extraño que se ejecute el otro código (ya que sale con un ret). ¿Alguna idea? Investigaré un poco más mi código en estas horas.

EI: juntando mensajes. No escribas mensajes consecutivos, edita.

Bueno, estuve revisando y encontré una supuesta solución (no funciona):

gcc -march=i686 -std=gnu99 -ffreestanding -c test.c -masm=intel
strip -R .eh_frame test.o
ld -o test -Tlink.ld test.o
objcopy -S -O binary test ..\programa.exe

¿está bien quitar esa sección? porque ahora no me muestra ningún mensaje. Cualquier noticia vuelvo a publicar.

EDIT:

Quedó así con el ndisasm:

Código [Seleccionar]

00000000  55                push ebp
00000001  89E5              mov ebp,esp
00000003  83EC10            sub esp,byte +0x10
00000006  C745FC00000000    mov dword [ebp-0x4],0x0
0000000D  31C0              xor eax,eax
0000000F  8B5DFC            mov ebx,[ebp-0x4]
00000012  CD80              int 0x80
00000014  C9                leave
00000015  C3                ret
00000016  90                nop
00000017  90                nop
00000018  48                dec eax
00000019  6F                outsd
0000001A  6C                insb
0000001B  61                popad
0000001C  206D75            and [ebp+0x75],ch
0000001F  6E                outsb
00000020  646F              fs outsd
00000022  20646573          and [ebp+0x73],ah
00000026  6465204743        and [gs:edi+0x43],al
0000002B  43                inc ebx
0000002C  2028              and [eax],ch
0000002E  49                dec ecx
0000002F  6E                outsb
00000030  7465              jz 0x97
00000032  6C                insb
00000033  205379            and [ebx+0x79],dl
00000036  6E                outsb
00000037  7461              jz 0x9a
00000039  782C              js 0x67
0000003B  207072            and [eax+0x72],dh
0000003E  6F                outsd
0000003F  677261            jc 0xa3
00000042  6D                insd
00000043  61                popad
00000044  2E657865          gs js 0xad
00000048  2920              sub [eax],esp
0000004A  7632              jna 0x7e
0000004C  2100              and [eax],eax
0000004E  0000              add [eax],al

Y adjunto la imagen resultante (archivo final):

Sigo sin comprender por qué tanto código (disculpa la ignorancia) ya que mi código en nasm sólo hice esto:

Código [Seleccionar]

[bits 32]
[org 0x10000]

jmp codigo
stringToPrint db "Hola mundo!", 0

codigo:
	xor	eax, eax
	mov	ebx, stringToPrint
	int	0x80
	ret	0

EDIT 2:

Y ahora que lo reviso bien el código no me genera ninguna excepción hasta que intento ejecutar el mismo comando. Voy adelantando: mi sistema usa una línea de comandos con múltiples pantallas (eso es lo de menos). Me explico mejor: el comando "ejecutar" (es temporal) ejecuta el programa "programa.exe" con normalidad (sin el strip) hasta que escribo el mismo comando y PAGE FAULT!. Lo más extraño es que funciona normal con nasm, y como ya había mensionado con el gcc pero quitando los supuestos bytes "basura" (garbage)

Eternal Idol · 3 Marzo 2013, 18:36 PM

¿Ejecuta el programa sin problemas una vez? Entonces esta claro que el problema es tu sistema y no los bytes posteriores al ret que nunca se llegan siquiera a ejecutar.

lweb20 · 3 Marzo 2013, 18:45 PM

Sí, tienes razón. Estuve revisando y el problema desaparece al quitar el "free" del administrador de memoria. Extraño.. super extraño. Ahí voy a sufrir ya que es muy complejo ese administrador de memoria :S

EDIT 1:

Pero aún así quiero saber qué son esas instrucciones (como dije no soy experto en asm). Por qué el gcc las crea y para qué. Sólo por curiosidad; y ¿está bien quitar la sección con strip?

EDIT 2:

Estoy probando el administrador de memoria con un ejemplo pequeño - usando 100000 bytes de memoria - y no me presenta problemas. Puede ser que la posición de memoria asignada por el programa ejecutable no sea la adecuada o algo así. Esa parte la tengo que estudiar bien. De todas maneras gracias por sacarme de varias dudas.

EDIT 3:

Alaa otro problema: El administrador de memoria parece estar bien. Resulta que todo está bien cuando descomento esta línea:

Código [Seleccionar]

_asm call programa

Que es la que ejecuta los bytes en la variable "programa". No sé que está pasando, en serio; ya probé de todo

Eternal Idol · 3 Marzo 2013, 19:06 PM

No son instrucciones, no es codigo, si te fijas es una sección de solo lectura ("Read Only" dice en el output de dumpbin).

Depura instruccion por instruccion hasta ver en cual falla exactamente y ahi mira los registros, la pila, etc..

lweb20 · 3 Marzo 2013, 20:15 PM

Acabo de hacer una depuración simple y el error está en call. Depuración simple es para mi por ejemplo:

PSEUDOCÓDIGO:

IMPRIMIR "leer archivo - inicio"
LEER_ARCHIVO
IMPRIMIR "leer archivo - fin"
etc...

Cualquier novedad aviso. Ahora voy a depurar con bochs

EDIT

Luego de corregir un problema que tenía con el bochs y la disquetera he descubierto algo que no tiene mucho sentido.

El error sigue ocurriendo pero cuando imprimo el contenido de la variable con un for y luego ejecuto el programa funciona todo correctamente.

Explicándome mejor:

Al solamente ejecutar el código con call sucede el page fault pero al imprimir la memoria de la variable en los dos casos (antes de copiarla a 0x10000 y después de copiarla) todo funciona normal.

EDIT 2

Una consulta. Por partes del manual que lei vi que se corregían algunos errores como ese page fault aumentando o disminuyendo el registro esp; ¿qué es lo que hace ese registro? no lo entiendo.

¡NOTICIA!

SOLUCIONÉ EL PROBLEMA

_asm pusha
_asm call programa
_asm popa

Pues lo que hice fue poner en el stack a los registros y luego liberarlos. Pero aún no entiendo el por qué :S ¿Alguien sabe la respuesta?

NOTICIA 2:

La solución era:

1. Abrir el archivo
2. Crear un buffer para los datos del archivo (malloc)
3. Leer el archivo y almacenarlo en el buffer
4. CREAR OTRA VARIABLE con la dirección de memoria 0x10000
5. Copiar el contenido del buffer a 0x10000
6. Liberar el buffer (free)
7. Ejecutar 0x10000
8. NO Liberar 0x10000 (no se debe liberar)

Gracias y ahí está la solución por si alguna otra persona como yo (

) tiene un problema similar xD

Gracias por todo. Problema solucionado

YEAH

Eternal Idol · 3 Marzo 2013, 23:42 PM

ESP = EXTENDED STACK POINTER. Es justamente el puntero a la pila (stack).

Por lo que pude entender el problema era que tu Kernel (asumo que esta escrito en C/C++) no contaba con lo que podia pasar en la funcion a la que llamabas por lo que si el compilador usaba algun registro (en este caso deberia ser EBX) para contener un puntero por ejemplo despues al hacer el call programa ese codigo lo cambiaba y entonces ... en fin ... ahora preservas los registros y funciona.

Si tenes ganas de probar podes ver que pasa si en lugar de usar inline assembly usas C:

Código [Seleccionar]

((void (*)(void))programa)();

Comparando el codigo ensamblador de tu Kernel podras ver si usaba EBX y si el compilador decide cambiar las cosas de alguna manera

lweb20 · 3 Marzo 2013, 23:46 PM

increible gracias

Fíjate el la solución 2 ya no uso el pusha ni el popa (aunque no lo dije

). Creo que el problema fue que nunca liberé la memoria del buffer ya que la moví directamente a 0x10000.

Eternal Idol · 3 Marzo 2013, 23:48 PM

De nada; y bueno, vaya uno saber, sin ver el codigo nada mas se puede adivinar pero si el problema era de memoria tiene sentido que funcionara una vez. Igual la clave esta en que puedas depurar en ensamblador instruccion por instruccion tu codigo, asi vas a ver siempre donde falla exactamente.