php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #20853 getting objectarray with 90 or more objects back from java produces a crash
Submitted: 2002-12-06 03:20 UTC Modified: 2003-08-20 23:58 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: andreas at billmann dot de Assigned:
Status: No Feedback Package: Java related
PHP Version: 4.3.0-dev OS: Linux
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2002-12-06 03:20 UTC] andreas at billmann dot de
I have php compiled with 
'./configure' '--prefix=/usr/local/php' '--with-apxs=/usr/local/apache/bin/apxs' '--with-java=/usr/java/j2sdk1.4.1'

I have added two simple Java sources and a php script to reproduce the error at the end of this description.
The error is a pointer error. Perhaps a variable gets a wrong pointer or the memory is changed during the mapping process from java to php.

I've found out, that the error happens in th HashTable struct. Here is a little extract from the logging I did in the zend_hash.c

ZEND_API int zend_hash_index_update_or_next_insert(HashTable *ht, ulong h, void *pData, uint nDataSize, void **pDest, int flag)
{
...
  nIndex = h & ht->nTableMask;
  syslog(LOG_CONS,"zend nIndex    : %d",nIndex);
  syslog(LOG_CONS,"zend tablesize : %d",ht->nTableSize);
  syslog(LOG_CONS,"zend elementnr : %d",ht->nNumOfElements);
...

Dec  6 10:15:08 abi httpd: zend nIndex    : 0
Dec  6 10:15:08 abi httpd: zend tablesize : 8
Dec  6 10:15:08 abi httpd: zend elementnr : 0
---------------------------------------------------
Dec  6 10:15:08 abi httpd: zend nIndex    : 0
Dec  6 10:15:08 abi httpd: zend tablesize : 8
Dec  6 10:15:08 abi httpd: zend elementnr : 0
---------------------------------------------------
Dec  6 10:15:08 abi httpd: zend nIndex    : 0
Dec  6 10:15:08 abi httpd: zend tablesize : 8
Dec  6 10:15:08 abi httpd: zend elementnr : 0
---------------------------------------------------
Dec  6 10:15:08 abi httpd: zend nIndex    : 11
Dec  6 10:15:08 abi httpd: zend tablesize : 16
Dec  6 10:15:08 abi httpd: zend elementnr : 10
---------------------------------------------------
Dec  6 10:15:08 abi httpd: zend nIndex    : 0
Dec  6 10:15:08 abi httpd: zend tablesize : 8
Dec  6 10:15:08 abi httpd: zend elementnr : 0
---------------------------------------------------
Dec  6 10:15:09 abi httpd: zend nIndex    : 1
Dec  6 10:15:09 abi httpd: zend tablesize : 8
Dec  6 10:15:09 abi httpd: zend elementnr : 1
---------------------------------------------------
Dec  6 10:15:09 abi httpd: zend nIndex    : 12
Dec  6 10:15:09 abi httpd: zend tablesize : 16
Dec  6 10:15:09 abi httpd: zend elementnr : 11
---------------------------------------------------
Dec  6 10:15:09 abi httpd: zend nIndex    : 0
Dec  6 10:15:09 abi httpd: zend tablesize : 12
Dec  6 10:15:09 abi httpd: zend elementnr : 138994948

The last entry is produced by the call from java.c
  zend_hash_index_update(Z_OBJPROP_P(presult), 0, &handle, sizeof(pval *), NULL);
in the method Java_net_php_reflect_setResultFromObject
and the nr in elementnr is the pointer to the next element!
I added some logging to the java class and saw that the number which is given back from jni for storing the next element is exactly that number!!! So it really seemst to be a pointer problem, but I can' t see if it is a problem of java.c or a problem of the php-engine.

Hope this helps!
Andi



Php2Java.java
--------------
package de.slab.php2java;
public class Php2Java 
{
	public SecondClass[] getSecondClassArray( int nr )
	{
		SecondClass[] sc = new SecondClass[nr];
		for ( int i=0; i < nr; i++ )
		{
			sc[i] = new SecondClass("SC "+i);
		}
		return sc;
	}
	
	public String[] getStrings( int nr )
	{
	  String[] sc = new String[nr];
	  for ( int i=0; i < nr; i++ )
	  {
	    sc[i] = "SC "+i;
	  }
	  return sc;
	}
}

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-12-06 03:24 UTC] andreas at billmann dot de
there was not enough space for the rest of the code, so I add it here:

package de.slab.php2java;
public class SecondClass
{
	private String name;
	public SecondClass(String name)
	{
		this.name = name;
	}
	
	public String getName()
	{
		return name;
	}
}

test.php
------------------------
<html>
<body>

<?php
  $php2Java = new Java('de.slab.php2java.Php2Java');
  // next line crashes with size of 90
  $arr = $php2Java->getSecondClassArray( 89 );
  // next line crashes with size of 131
  $arr = $php2Java->getStrings( 130 );
?>
</body>
</html>
 [2002-12-06 03:37 UTC] edink@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

I've just tried your example and it worked fine (using Sun's JDK 1.3.1).
 [2002-12-06 04:01 UTC] andreas at billmann dot de
You have seen the comments that it crashes with the value of 90 and 131? And have you tried it with values higher between 10.000 and 50.000? This is the range I need, because I have to
show a directory of a terabyte hd where all the files are in one directory.

I'm currently downloading the latest php and try it on my own. I will post the resutlts here again.

Thx,
Andi
 [2002-12-06 04:16 UTC] edink@php.net
I've tried it now with 50.000 and it worked. It took about 3.6 seconds on my P3 600.
 [2002-12-06 04:38 UTC] andreas at billmann dot de
Ok, now the values are about 190.000 for the object array
that is a value I can live with and 200 (it works for 199 and crashes with 200) for the string array. So when I need a big array with strings I wrap them in an object.

Thx for your help.
Andi

PS: I have jdk 1.4.1 on a P4 1500 with 768MB and Suse Linux 8.1
 [2002-12-06 04:44 UTC] andreas at billmann dot de
I'm sorry,
my the example works now fine, but with a more complex class (FileInfo extends java.io.File and implements Serializable) it fails with an array of the size 15.

I don't have added the logs this time, so I don' t know if this is the same error or not, but I can't test this until monday, so I update this on monday.

Thx for your help and have a nice weekend.
Regards,
Andi
 [2002-12-06 06:24 UTC] sniper@php.net
updated the PHP version info.

 [2002-12-09 01:04 UTC] andreas at billmann dot de
In php4-200212060830 the error that happens with the more complex ojbect is the same error described before.
There are some bugs in the memory management.
--------------------------------------------------
Dec  9 08:06:18 abi httpd: zend nIndex    : 0
Dec  9 08:06:18 abi httpd: zend tablesize : 8
Dec  9 08:06:18 abi httpd: zend elementnr : 0
--------------------------------------------------
Dec  9 08:06:18 abi httpd: zend nIndex    : 1
Dec  9 08:06:18 abi httpd: zend tablesize : 8
Dec  9 08:06:18 abi httpd: zend elementnr : 1
--------------------------------------------------
Dec  9 08:06:18 abi httpd: zend nIndex    : 13
Dec  9 08:06:18 abi httpd: zend tablesize : 16
Dec  9 08:06:18 abi httpd: zend elementnr : 11
--------------------------------------------------
Dec  9 08:06:18 abi httpd: zend nIndex    : 0
Dec  9 08:06:18 abi httpd: zend tablesize : 13
Dec  9 08:06:18 abi httpd: zend elementnr : 137413676

Bye,
Andi

PS: I download the current php packages and try them.
 [2002-12-09 01:59 UTC] andreas at billmann dot de
With version php4-200212090630 I could create an array with more than 300.000 objects or strings (I didn' t test more because this is enough for my application), but the array with the more complex FileInfo class fails again.

I will try future snapshots and report the status of this problem but I will do a work around for my application with wrappers and simple objects.
 [2003-08-20 23:58 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 22:01:29 2024 UTC