Bug com abas em ambiente linux

Olá,

Temos enfrentado problemas com uma aplicacao do tipo formulario quando criamos duas ou mais páginas e quando a tabela tem fisicamente mais de 100 campos.

O padrao de comportamento é o seguinte:

  • Em ambiente windows tudo funciona corretamente sem nenhum problema em todos os cenarios.

  • Em ambiente linux (debian lenny) com apache ou lighttpd, mysql e php (mod_apache ou fastcgi) algumas tabelas do sistema, como exemplo uma que tem 110 campos, funcionam perfeitamente no formulario se eu colocar tudo socado em uma unica pagina, mas se eu mandar paginar, o formulario entao abrirá somente com as abas das paginas, mas os campos de nenhum formulario aparecerá.
    Me parece relacionado a quantidade de campos da tabela em questão e nao a quantidade de campos usados. Digo isto porque basta colocar duas paginas no formulario com apenas um campo por pagina que o problema ocorre.
    Notem que, se eu pegar uma tabela menor, que tem fisicamente 10 campos, e fazer o mesmo teste (2 paginas e 1 campo por pagina) tudo funciona no ambiente linux, mas se eu fizer o teste com a tabela que tem 110 campos… dá pau.

Neste caso, até entendo que seja ambiente, mas sendo assim, é algo que possa ser configurado (se for configuracao entao o que deve ser mudado) ou é algo que simplesmente é totalmente não identificado e pronto ?
Alguem aqui no forum já passou por este tipo de problema ?

Obrigado pela atencao.

Ja tentou isso de outra maquina? acessar pelo navegador de outra maquina?

Ta me cheirando talvez a memoria … o excesso de inputs no html, jogam a memoria la pra cima do navegador. Talvez o navegador nao esteja processando direito …

apenas um teste pra voce ir testando …

Olá Diogo,

Obrigado pela resposta.
Acho que não fui claro em minha exposicao, entao vou tentar denovo.

Agora que voce mencionou, apesar de ja ter tentado com 4 navegadores (ie, firefox, safari e opera) tentando acesso em 3 servidores distintos (um windows onde desenvolvo e outros dois linux, o ultimo inclusive com instalacao completa hoje usando inclusive outro server web (“lighttpd”) eu realmente nao havia tentado sentar em outro computador para testar. Bom, fiz isso e continuou igual (o mesmo erro persistiu), usei 3 navegadores somente porque do opera eu ja desisti. Se alguem tentar abrir o scriptcase nele vai entender o que estou falando. E realizei acesso aos meus 3 servidores. Beleza, tudo continuou igual ao padrao que indiquei na mensagem anterior e o problema persistiu.
Sabe, me ocorreu que voce pode ter razao sim, pode ser memoria ou algum parametro relacionado a memoria. Mas isto do lado do servidor com o php para poder fazer a coisa funcionar, pois como mencionei, onde instalei no windows funcionou direitinho, mas no linux nao. Não imagino o que ocorre para levar a isto em um ambiente e em outro nao.
Entendi o detalhe do “muitos inputs” e todo o resto, só gostaria que ficasse claro que, apesar da tabela ter mais de 100 campos, o lance dá pau quando eu coloco apenas 2 no formulario (informei isto no post anterior)… só 2, a tabela tem fisicamente mais de 100 campos mas eu so coloco nos campos selecionados para exibir e gerar input somente 2. Desta forma devo ter só 2 inputs, o que deveria nao ter impacto no browser, mas mesmo que o SC coloque tudo como hidden ou qualquer outra porcaria, porque no windows ele nao dá pau em browser e no linux dá ? Veja, o navegador e o computador cliente é o mesmo (winxp sp3 + ie ou safari ou firefox). Este mesmo computador cliente consegue abrir normalmente uma pagina gerada dentro de um outro servidor windows, mas se a mesma aplicacao foi copiada do server windows e colada no server linux, quando eu pegar a mesma estacao cliente windows xp e acessar o server linux dá o problema. Neste sentido me parece claro que o problema nao é relacionado ao navegador, mas sim ao ambiente. Pode ser memoria como voce mencionou, contudo, parece claro que é no ambiente do servidor e nao na estacao.

No que diz respeito a ficar tentando, tudo bem, acho valido explorar. Mas eu fiquei tentando quase um mes antes de vir encher o saco aqui no forum. Até pouco tempo postei outra questao aqui no forum, depois de ter tentato muito, e o resultado foi o seguinte. Algum companheiro me deu um macete para que eu pudesse continuar vivendo daquela forma, era um bug mesmo e ia continuar sendo pelo que entendi. Bom, fiz o que ele indicou, deu certo e ficamos nos adaptando a erros da ferramenta. OK, tudo bem, se for para ser assim beleza, vamos continuar.
Mas ficar tentando buscando no browser a resposta acho que nao é valido nao.
Como mando gerar somente 2 inputs e constatei que quando a tabela tem muitos campos aí sim dá pau (mesmo que tenha colocado somente 2 deles), então entendo que é um bug relacionado a ferramenta.
Se chegarmos a conclusão que o problema é a quantidade de campos da tabela que provoca de alguma maneira um estouro de memoria, pra mim tudo bem, só preciso saber se há alguma forma de contornar isto pois está estourando dentro do servidor linux somente mesmo quando nao deveria (se tem 110 campos e só uso 2, deveria instanciar somente 2).
Voce saberia me informar qual parametro ou variavel PHP que deve ser modificada para ser possivel conviver com isto ?
Postei em bugs por causa disto, se for memoria, está ocupando indevidamente. Mas como meu objetivo não é criticar a mecanica ou a filosofia da ferramento, ficarei muito feliz se algum colega que com certeza já está acostumado com este tipo de situação poderia me ajudar, talvez indicando o que devo fazer para resolver o problema.

Obrigado pela atenção.

Desculpe deepcat, mas eu não tenho com saber dos seus problemas anteriores.
Como todos sabem estou aqui apenas para tentar dar um help ao pessoal do forum, não é de minha obrigação e não sou da equipe de suporte. Voce tambem nao citou que esta a mais de um mes tentando antes de vir perturbar aqui, não sou adivinho.

Então se voce teve um bug, deveria ser relatado para bugs@scriptcase.com.br e não um usuario que disse que eh um bugzinho e voce aceitou conviver com ele … nos nao estamos sabendo … pois o forum é de uso dos clientes, embora de fato estamos tentando ajudar a movimentar e tudo mais.

Então dou dicas para que a gente possa rastrear o problema. Ja que voce tentou, visto que os outros campos tem que ser trafegados via hidden pois o usuario(vc desenvolvedor) pode manipular os mesmo … tenta rastrear no servidor(linux) como esta o comportamento de memoria e processador quando voce abre a aplicação.

Ve o memory_limit tambem do php.ini

Olá,

Amigão, valeu pela resposta.
No caso de voce saber de minhas solicitacoes anteriores, voce está certo, voce nao tinha como saber mesmo, e nem era o que eu esperava. Meu assunto é relacionado a problemas que encontramos no produto ScriptCase da empresa NetMake, ela sim deveria saber. Você deve fazer parte dela até onde eu entendi, logo não foi prudente voce ter levado para o lado pessoal, como foi o que pareceu.
Fique tranquilo pois sabemos que a responsabilidade de voces e obrigação, como voce mesmo disse, aqui no forum é nenhuma, afinal voce nao é suporte e tudo mais e está somente tentando dar um help… Sabemos bem disso. Lembre-se que ao final menciono que esperava ajuda de um colega, pois na pratica nao recebemos ajuda de voces por aqui mesmo.
Ok, bem entendido. Estamos todos acostumados com isto mesmo.
No caso do memory limit, foi setado para 1024M e ainda assim nao resolveu. Visto que minha base de testes é de 10MB, nao fiz testes com conteudo acima disto.
Nos logs, nada aparece quando chamamos a tela.

Obrigado pela atencao

Como esta o processador do servidor? e a memoria?

Estranho que isso so aconteça no linux. Essa tabela com 100 campos é no MySQL?

Teria algum problema passar estrutura e dados ou são confidencias? Para que eu possa testar na minha maquina?

To com o ubuntu … diz a versão do apache, php, zend que tas testando.

Olá,

Obrigado pelo apoio Diego.
Abaixo segue o schema da tabela. Ela é no MySQL sim.
Sobre os servidores (testei em dois diferentes que apresentaram o mesmo problema) temos:
Ambos os servidores estão virtualizados com Hypervisors diferentes.

1 - Processador Intel Core i5 650 (3.2Ghz) rodando Linux e com virtualização Host VirtualBox.
Maquina Virtual alocando 2 cores em frequencia maxima, 1 Gb de memoria, 100Gb de HD
Não há outras maquinas virtuais rodando. Durante os testes com a aplicacao scriptcase sendo executada, o pico de processamento, tanto no host quando no guest atingiram marcas abaixo dos 20% durante todo o processo, memoria consumida pelo ambiente web rodou sempre abaixo dos 100MB.
Nesta VM temos:
- Linux debian 2.6.26-2-amd64 #1 SMP Thu Oct 25 15:56:38 UTC 2010 x86_64
- lighttpd/1.4.19
- Server API: CGI/FastCGI
- PHP Version 5.2.14-0.dotdeb.0
- Suhosin Patch 0.9.7
- Zend Engine v2.2.0 (Zend Extension 220060519)
- MySQL Server 5.1.51-0.dotdeb.1

2 - Processador Intel Xeon E5640 (2.66Ghz) rodando Linux e com virtualização Host Xen.
Maquina Virtual alocando 2 cores em frequencia maxima, 1.5 Gb de memoria, 20Gb de HD
Não há outras maquinas virtuais rodando. Durante os testes com a aplicacao scriptcase sendo executada, o pico de processamento, tanto no host quando no guest atingiram marcas abaixo dos 5 % durante todo o processo, memoria consumida pelo ambiente web rodou sempre abaixo dos 100MB.
Nesta VM temos:
- Linux server07 2.6.26-2-xen-amd64 #1 SMP Thu Aug 20 00:36:34 UTC 2009 x86_64
- Server API: Apache 2.0 Handler
- Apache/2.2.9 (Debian)
- PHP Version 5.2.6-1+lenny3
- Suhosin Patch 0.9.6.2
- Zend Engine v2.2.0 with XCache v1.2.2,(Zend Extension 220060519)
- MySQL Server 5.1.49-0.dotdeb.0-log

Adicionalmente, ainda testei com os webservers Nginx e litespeed.
No caso do Nginx, ficou um pouco mais lento, mas o resultado foi o mesmo.
No caso do litespeed foi só desgraça, nada deu certo, o ambiente de producao logava mas ao clicar nos links dentro para criar a ligacao com o banco nada abria. A aplicacao dizia que faltava o mbstring e precisava disto para funcionar. Até tentei mecher no litespeed para ver se chegava a fazer funcionar, compilando denovo o php e tal, mas como realmente nunca tinha usado este webserver é claro que eu ia apanhar muito para fazer ele funcionar direito para depois verificar a aplicacao gerada no scriptcase, entao desisti por nao saber operar o litespeed.

Abaixo segue a definicao da tabela.
Mais uma vez obrigado pela atenção.

Create table Clientes (
CodCliente Varchar(10) NOT NULL,
CodCliVendedor Varchar(10),
CodEmpTitulo Varchar(10),
CodTitulo Varchar(20),
Nome Varchar(50),
NomFantasia Varchar(50),
CNPJ Varchar(20),
CodEmpFunVendedor Varchar(10),
CodFunVendedor Varchar(10),
CodRamAtividade Varchar(20),
CodOriCliente Varchar(20),
CodAreInteresse Varchar(20),
Endereco Varchar(50),
Numero Varchar(10),
Complemento Varchar(50),
Bairro Varchar(50),
CEP Varchar(10),
Pais Varchar(50),
Estado Varchar(50),
Municipio Varchar(50),
CodBairro Varchar(20),
CodZona Varchar(20),
Email Varchar(255),
Observacao Longblob,
CodMunicipio Varchar(10),
AreFiscal Varchar(10),
CFOP Varchar(10),
IE Varchar(20),
Fone Varchar(100),
Fax Varchar(100),
DatCadastro Date,
DatMovimentacao Date,
DiaPriPagamento Int,
DiaSegPagamento Int,
DiaTerPagamento Int,
Tipo Int,
TipCobranca Int,
CodEmpresa Varchar(10),
Status Int,
Portador Int,
PesCubagem Double,
Substituto Int,
InsSuframa Varchar(50),
Incentivado Int,
CamRemEDIFACT Varchar(255),
CamEntEDIFACT Varchar(255),
ColEndereco Varchar(50),
ColNumero Varchar(10),
ColComplemento Varchar(50),
ColBairro Varchar(50),
ColCep Varchar(10),
ColPais Varchar(50),
ColEstado Varchar(50),
ColMunicipio Varchar(50),
IM Varchar(20),
ProRural Varchar(1),
ConICMS Varchar(1),
SomValTotPrestacao Double,
SomPesCubado Double,
SomResultado Double,
Contato Varchar(250),
PraValidade Varchar(20),
PraEntrega Varchar(20),
TipCadastro Int,
RG Varchar(20),
OrgExpRG Varchar(20),
dia1 Int,
dia2 Int,
dia3 Int,
dia4 Int,
dia5 Int,
ValLitDiesel Double,
ValLitGasolina Double,
ValLitAlcool Double,
ValMetCubGas Double,
EnvInfSite Int,
CodTabVenda Varchar(20),
PerICMS Double,
Enviado Int,
Sent Int,
CodPais Varchar(20),
CodEstado Varchar(20),
IESubstituto Varchar(20),
CNAE Varchar(20),
CTPS Varchar(20),
CTPSerie Varchar(20),
CTPUF Varchar(20),
CTPDatEmissao Date,
CTPDatValidade Date,
Prontuario Varchar(20),
INSS Varchar(20),
NomPai Varchar(50),
NomMae Varchar(50),
Habilitacao Varchar(20),
CatHabilitacao Varchar(20),
CerHabilitacao Varchar(20),
MunEmiHabilitacao Varchar(50),
DatEmiHabilitacao Date,
DatVenHabilitacao Date,
PlaCavalo Varchar(20),
PlaCarreta Varchar(20),
DatEntrada Date,
DatEmiRG Date,
DatNascimento Date,
UFEmiRG Varchar(20),
QuaDependentes Int,
RTB Varchar(20),
MunEmiRG Varchar(50),
TipEDI Int,
RNTRC Varchar(50),
Comissionavel Int,
Primary Key (CodCliente)) ENGINE = InnoDB;

Create Index CliNomIDX ON Clientes (Nome);
Create Index CliNomFanIDX ON Clientes (NomFantasia);
Create UNIQUE Index CliCNPIDX ON Clientes (CNPJ);
Create Index IDXCOLFAST007 ON Clientes (CodCliente);

Olá,

 Não sei se pode te ajudar em alguma coisa, mas meu servidor de desenvolvimento e meu servidor de produção são máquinas linux, e eu até pouco tempo atrás reclamava de problemas que ocorriam no linux mas não no windows. No caso eram outros problemas pois não possuo tabelas aqui com tantos campos. Vendo sua configuração gostaria de saber se o seu php esta com o pacote php5-suhosin instalado, o suhosin por padrão ja esta em outros pacotes do php, mas acho que apenas uma pequena parte dele, aqui eu tinha este pacote instalado e meu scriptcase linux apresentava problemas que não apresentava no windows, checando bem a configuração do php de ambos os sistemas a única coisa que percebi que estava diferente era este modulo do suhosin que tinha no linux mas não tinha no windows, no linux eu removi o php5-suhosin, mas mesmo assim parte dele fica, isto ficou padrão no php5 para linux. Bom depois de remover não tive mais problemas, inclusive tenho um ticket aberto pedindo para o pessoal da netmake analisar este suhosin, pois ele no linux via pacote esta se tornando obrigatorio. Senão temos que instalar o php na mão.
 Esta é apenas uma dica para vc ver pois pode não ser o seu caso, é que comigo este modulo suhosin instalado fez muita diferença e no windows ele não é instalado.

Abraços.

envie a configuração de seu php

 Meus servidores tanto desenvolvimento como produção são Linux debian 2.6.26-2-amd64, abaixo link com a descrição dos dois servidores:

http://www.peruibe2.sp.gov.br/download/desenvolvimento.htm

http://www.peruibe2.sp.gov.br/download/producao.htm

 Na época que passei por problemas estranhos eu pedi ao pessoal da netmake uma licença provisória de 10 dias, com essa licença eu montei um servidor windows 2003 server, baixei a versão completa para windows que instala tudo até o ambiente web e migrei toda a minha aplicação para lá, não abandonei nem meu servidor de desenvolvimento nem o meu de produção em linux pois nunca quisemos isso aqui onde trabalho. Foi ai que percebi que tudo que não esta de acordo no linux funcionava corretamente no windows, por isso comecei a comparar as informações de ambiente do windows com o linux e de tudo o que vi foi esse modulo suhosin que não possui no windows como comentei acima. Bom fiz todos os acertos inclusive removi o php5-suhosin que estava instalado, mas mesmo assim alguns modulos do php trazem o suhosin mas acho que só uma parte dele, depois disso ficou tudo normal. Não instalei o php na mão para poder remover em definitivo o suhosin, utilizei os pacotes do debian, como meu servidor de produção ja estava em total utilização não quisemos mexer no time que estava ganhando.
 Infelizmente a maquina windows que montei não existe mais, inclusive ela foi formatada e é utilizada em outra coisa, por isso não possuo mais informações dela.

Olá,

antloufer, fiz o que voce mencionou, poxa, nao deu certo, o problema persiste.
Vou procurar rastrear de alguma outra maneira em relacao ao que está dando errado.
Já coloquei para registrar o log do PHP até com E_STRICT e nada.
Incrivel, só são exibidas as abas e o mais interessante é que aparentemente a produção da página é que está comprometida, pois ao clicar nas abas o I.E. informa o erro de que o objeto container nao existe. E olhando a pagina produzida ele realmente não é encontrado no codigo html resultante. Impressionante.
Aquele outro bug que relacionei neste mesmo topico, a pagina tambem nao era construida, havia um erro na geracao, só que naquele caso ocorria uma mensagem de erro e a pagina com problema vinha errada do gerador, só que essa sai certa do gerador e roda no windows, mas no linux nao. Sei lá, talvez o problema esteja em algo a mais que nao encontrei na distribuicao debian (voce mencionou o suhosin e acredito que ele possa causar mesmo um monte de problemas pois limita o consumo de recursos por scripts de uma maneira nao muito convencional, só que é padrao do debian e talvez de outras, e realmente nao parece bom).

Harold, segue o link do meu tambem.
http://216.119.146.33/info.htm
Vou procurar relacionar agora o meu php com o do antloufer e ver se há algo que eu consiga fazer.
A diferenca de performance, estabilidade e possibilidades no linux são imensas, nao é possivel que não tenha jeito. Até já arrumei uma forma de deixar a pagina de clientes mais “parecida” com o que eu precisava, só que tive que encher ela de botoes, ligacoes e outras tranqueiras, mas isto vai me prejudcar mais na medidade de padronizacao (esta tela já ficou nada a ver com as demais) e em produtividade (1 mes e 1 semana pastando pra descobrir o porque disto) caso apareca em outras telas… fazer o que né ?

Amigos, agradeço muito mesmo pela ajuda de voces. Sei do interesse de voces também por buscar solucoes para estas “coisinhas” que acontecem com todos nós. Por aqui, já estou instalando um CentOS e um Slackware para ver se encontro alguma forma de saír de mais essa.

Até mais

Olá,

Para adicionar mais algumas informacoes.
Conforme mensagem anterior, instalei o CentOS e o kit apache + php + MySQL, tanto do repositorio quanto na mão (apache + php) e nada. Sempre o mesmo erro.
Ainda conforme mencionado na mensagem anterior, desisti de procurar a resposta, mas acabei ficando nesta situacao só por poucas horas, pois ao iniciarmos novamente o teste de nosso projeto por inteiro no ambiente linux, lá aparece novamente o problema com abas, mas desta vez com uma tabela que tem apenas 3 campos… aí foi pra lascar.
Pensei que o problema era relacionado de alguma forma com a quantidade de campos, mas testando a aplicação toda, descobrimos que exclusivamente no ambiente linux existem telas com abas que nao abrem alem de nosso cadastro de clientes.
Percebí lendo o código HTML inteiro que a quantidade de linhas que uma mesma aplicacao gera no ambiente windows é maior que a que gera no ambiente linux.
Encontrei também ao final do arquivo html gerado pelo linux a diferença quando procuro pela mesma linha do gerado pelo windows. O linux entega a pagina incompleta (isso tanto faz a versao do PHP que ficou entre a 5.2.4 e 5.2.14 – e tanto faz a versao do apache/lighttpd).
A pagina gerada pelo linux pára ao gerar a primeira incidencia do trecho de código indicado abaixo.

<!-- bloco_f -->
   </div>

Até onde entendí esta marca é relacionada aos blocos. Ela precede a geracao de cada bloco dentro das paginas geradas, entao, se eu tiver 10 blocos, aparecerao 10 sessoes sendo comentadas conforme o código acima.
Nas paginas que estao dando problema, como esta de 3 campos que eu mencionei, tenho apenas 2 blocos, um em cada página.
Na pagina gerada em ambiente windows tive 2 blocos gerados e na pagina gerada em ambiente linux a pagina que pode ser visualizada pelo browser tinha sua ultima linha exatamente no ponto onde ocorre a primeira emissao desse bloco constatado na pagina gerada pelo windows que ficou maior por conter esta e todas as incidencias posteriores e todo o conteudo agregado e posterior.
O efeito que isto tem é que a pagina forma as “orelhas” das abas mas nao completam seu “corpo”, que vem pelos blocos.
Bom, se alguem tiver uma ideia do que pode estar causando isto, agradeço muito…

Grato pela atenção.

Pessoal, só para constar.
Algo bom na 5.2 (apesar de eu nunca ter encontrado o que realmente deu errado na 5.1 relacionado a isto).
Nesta nova versao, quando tudo é instalado no servidor 100% SC5.2 (apl e prod) funciona sem problemas.