[RESOLVIDO]Erro na dll ntdll.dll em aplicação JAVA

Programação Java
#1

Tenho uma aplicação de ECF desenvolvida em java e do nada a aplicação fecha e cria um arquivo de log no diretorio principal

[code]# A fatal error has been detected by the Java Runtime Environment:

EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7707205b, pid=3288, tid=188

JRE version: 6.0_22-b04

Java VM: Java HotSpot™ Client VM (17.1-b03 mixed mode, sharing windows-x86 )

Problematic frame:

C [ntdll.dll+0x5205b][/code]

pesquisei na internet mas nao encontrei resolução, só encontro de desinstalar e instalar de novo o java mas ja fiz isso e nada, pq esse erro acontece?

É concorrencia de memoria entre a aplicação e o SO?

Obs: esse erro só acontece no windows Vista e 7

#2

Sua aplicação de ECF usa JNI, ou JNA, ou então faz assinatura digital com smartcards?

#3

A aplicação acessa uma dll do fabricante da impressora por JNA

import com.sun.jna.Native; import com.sun.jna.win32.StdCallLibrary;

#4

Isso só com o fabricante; só ele que consegue ajudar a resolver esse tipo de coisas escabrosas.

#5

O problema é que o fabricante nao esta identificando o problema…
e esse erro ocorre nao quando eu mando um comando pra impressora atraves da dll mas em momentos de abrir um novo JDialog por exemplo, estou no frame principal e mando abrir um novo jdialog fecha a aplicação, parece que nao foi possivel alocar memoria mas estou fazendo o teste com -Xss32M onde o fabricante sugere 8M apenas

#6

Experimente, ao chamar o programa, passar o parâmetro -Xcheck:jni

C:> java -X

C:\>java -X
    -Xmixed           mixed mode execution (default)
    -Xint             interpreted mode execution only
    -Xbootclasspath:<directories and zip/jar files separated by ;>
                      set search path for bootstrap classes and resources
    -Xbootclasspath/a:<directories and zip/jar files separated by ;>
                      append to end of bootstrap class path
    -Xbootclasspath/p:<directories and zip/jar files separated by ;>
                      prepend in front of bootstrap class path
    -Xnoclassgc       disable class garbage collection
    -Xincgc           enable incremental garbage collection
    -Xloggc:<file>    log GC status to a file with time stamps
    -Xbatch           disable background compilation
    -Xms<size>        set initial Java heap size
    -Xmx<size>        set maximum Java heap size
    -Xss<size>        set java thread stack size
    -Xprof            output cpu profiling data
    -Xfuture          enable strictest checks, anticipating future default
    -Xrs              reduce use of OS signals by Java/VM (see documentation)
    -Xcheck:jni       perform additional checks for JNI functions
    -Xshare:off       do not attempt to use shared class data
    -Xshare:auto      use shared class data if possible (default)
    -Xshare:on        require using shared class data, otherwise fail.

The -X options are non-standard and subject to change without notice.
#7

Executei com esse parametro e agora ele vai me mostrar um log de erro mais apurado?

#8

Não sei exatamente o que ele faz. Eu sei que vários colegas que mexem com JNI dizem que é necessário usar esse parâmetro para pegar erros bobos no JNI. Como você está usando JNA, no entanto, pode ser que não ajude muito.

#9

Entendi observando os parametros eu sempre aumento a memoria da memoria estatica vou agora setar mais memoria RAM para testar

[code]# -Xms set initial Java heap size

-Xmx set maximum Java heap size

-Xss set java thread stack size [/code]

eu só estava utilizando o Xss

#10

Eu recomendo mexer pouco no -Xss (o default do Java é 128K, mas pode usar até uns 8M, conforme foi indicado pelo fabricante. Não use mais que isso). Onde você costuma ter de mexer é no -Xmx.

#11

Resolvi o problema estava no retorno da dll onde o array de byte deveria receber um byte a mais pois em C sempre retorna o ultimo como 0, com isso a aplicação em java estava recebendo 1 byte a menos e em determinado tempo dava problemas na instanciação do objeto
aumentando um byte em cada metodo de retorno da dll ficou certo.

Obrigado.

#12

Olá furacao123, esta implementação de aumentar em um byte em cada metodo de retorno da dll foi feita na dll ou em sua aplicação java? Se foi na dll te pergunto, você alterou a dll ou a fabricante do ECF? Ainda se foi na dll poderias me passar a mesma ou informar onde eu poderia baixar esta dll alterada? Outra coisa, poderias me passar qual o modelo de ECF que apresentou este problema (Elgin, Epson, Bematech ou …)

#13

DouglasCar ja faz um tempo que tive esse problema, e ja faz um tempo que não mecho com ECF, mas lembro que o problema foi resolvido no JAVA, nao teve alteração nenhuma em DLL, eu tinha muito problema com impressoras Epson, pelo que eu me lembre era com ela esse problema.
Outra coisa tinha um problema na Epson ao fazer a Redução Z, dava estouro de memoria static, tinha que rodar a aplicação aumentando o Xss.

#14

Obrigado pelo retorno furacao123, estamos enfrentando o problema de fechamento da aplicação e ao verificarmos o arquivo de log gerado no diretorio principal da aplicação sempre encontramos o erro com a ntdll.dll. Só que no nosso caso a impressora é Elgin, mas enfim valeu pela ajuda.

#15