bluecove-gpl *** stack smashing detected ***

[somatik]

Hi all,

I was testing the latest build of bluecove-gpl today and when updating
a service record I get a total jvm crash with this message:

*** stack smashing detected ***: /usr/lib/jvm/java-6-sun-1.6.0.03/jre/
bin/java terminated
Java Result: 134

localDevice.updateRecord(record);

any idea?

[Vlad Skarzhevskyy]

Can happen.
Need all the details you can give.
1. Linux kernel version and BlueZ
2. The best is to give me your record in java format.
3. The crush files generated.
4. Did you took binary from our build or build them yourself. Try
bailing them yourself does it change the outcome?

Vlad

[somatik]

On Jan 28, 2:05 pm, "Vlad Skarzhevskyy" <skarzhevs...@gmail.com>
wrote:

> Can happen.
> Need all the details you can give.
> 1. Linux kernel version and BlueZ

Ubuntu 7.10
Linux 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686 GNU/
Linux
bluez 3.19

> 2. The best is to give me your record in java format.

DataElement base =
record.getAttributeValue(IMAGES_NAMES_ATTRIBUTE_ID);
DataElement de = (DataElement) dataElements.get(name);
if (de == null) {
de = new DataElement(DataElement.STRING, name);
dataElements.put(name, de);
}
if (isPublished) {
base.addElement(de);
} else {
if (!base.removeElement(de)) {
System.err.println("Error: item was not removed for: "
+ name);

return false;
}
}

record.setAttributeValue(IMAGES_NAMES_ATTRIBUTE_ID, base);

try {
localDevice.updateRecord(record);
} catch (ServiceRegistrationException e) {
gui.log("Can't update record now for: " + name);
gui.log(e);
return false;
}

this is some demo code from the sun website somewhere, I run this code
about 10-30 times (for each name) and he crashes somewhere in between
depending on the 'name' contents I suppose or some other mem
problem...

> 3. The crush files generated.

where do I find those crash files? I'm testing my code in Netbeans.

> 4. Did you took binary from our build or build them yourself. Try
> bailing them yourself does it change the outcome?

Took the binary from the site, i'll try building my own but where is
the bluecove-gpl svn repo located?

>
> Vlad

[Vlad Skarzhevskyy]

svn:
http://bluecove.googlecode.com/svn/bluecove-gpl/trunk

Do you call localDevice.updateRecord(record); in a loop or just once?

Give me the number for you IMAGES_NAMES_ATTRIBUTE_ID and examples of
the name e.g. Lenght of the String. Is it UTF or just US ASCII.

The JVM crash files are located in the process current directory.
Look at the root of your project or in linux user home.

--
Vlad

[somatik]

in a loop, for each name in the code below

private static final int IMAGES_NAMES_ATTRIBUTE_ID = 0x4321;

for the strings:
for (File file : rootDir.listFiles()) {
files.put(file.getName(), file);
names.add(file.getName());
}

I couldn't find the crash files, what do they look like? Are they
always generated?
Checking out svn right now

Thanks
Francis


On Jan 28, 3:41 pm, "Vlad Skarzhevskyy" <skarzhevs...@gmail.com>
wrote:

> svn:http://bluecove.googlecode.com/svn/bluecove-gpl/trunk
>
> Do you call localDevice.updateRecord(record); in a loop or just once?
>
> Give me the number for you IMAGES_NAMES_ATTRIBUTE_ID and examples of
> the name e.g. Lenght of the String. Is it UTF or just US ASCII.
>
> The JVM crash files are located in the process current directory.
> Look at the root of your project or in linux user home.
>

[somatik]

built the bluecove-gpl myself and now i'm getting this

javax.bluetooth.BluetoothStateException: BlueCove not available

[Vlad Skarzhevskyy]

How may file in root?
You know that service record has a size limit? I will enforce it in a code.
Vlad

--
Vlad

[somatik]

could be that, any idea why my own compiled version doesn't work?

On Jan 29, 4:30 pm, "Vlad Skarzhevskyy" <skarzhevs...@gmail.com>
wrote:

> How may file in root?
> You know that service record has a size limit? I will enforce it in a code.
> Vlad
>

[Vlad Skarzhevskyy]

Sorry I don't know yet why it is not working in your case....
I will try Ubuntu 7.10 next week.
For now I converted all native code to C from C++ to make it less
dependent on system libraries let me know if it makes any difference.

[somatik]

updated from svn
all tests fail with the following stacktraces:

cat com.intel.bluetooth.ServiceRecordTest.txt
-------------------------------------------------------------------------------
Test set: com.intel.bluetooth.ServiceRecordTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.023
sec <<< FAILURE!
testServiceRecordConvert(com.intel.bluetooth.ServiceRecordTest) Time
elapsed: 0.001 sec <<< ERROR!
java.lang.Error: Can't load SO
at
com.intel.bluetooth.NativeTestCase.setUp(NativeTestCase.java:61)
at junit.framework.TestCase.runBare(TestCase.java:125)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:
124)
at junit.framework.TestResult.run(TestResult.java:109)

cat com.intel.bluetooth.NativeDebugTest.txt
-------------------------------------------------------------------------------
Test set: com.intel.bluetooth.NativeDebugTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.126
sec <<< FAILURE!
testDebug(com.intel.bluetooth.NativeDebugTest) Time elapsed: 0.08
sec <<< ERROR!
java.lang.UnsatisfiedLinkError:
com.intel.bluetooth.BluetoothStackBlueZ.enableNativeDebug(Ljava/lang/
Class;Z)V
at
com.intel.bluetooth.BluetoothStackBlueZ.enableNativeDebug(Native
Method)
at
com.intel.bluetooth.NativeDebugTest.testDebug(NativeDebugTest.java:44)


On Jan 31, 4:54 am, "Vlad Skarzhevskyy" <skarzhevs...@gmail.com>
wrote:

[Vlad Skarzhevskyy]

In one of the log files in directory target/surefire-reports there
should be a message describing why native shared object can't be
loaded. Can you find it?

[somatik]

Tests run: 4, Failures: 0, Errors: 0, Skipped: 0

hooray :-)

but thi initial problem is still there:

*** stack smashing detected ***: /usr/lib/jvm/java-6-sun-1.6.0.03/jre/
bin/java terminated
Java Result: 134

did you add the check for the record size?

////////

via mail:
Hi Francis
I see when using yours .so
undefined symbol: __stack_chk_fail_local

ubuntu devs decided to have -stack-protector on by default!

I added -fno-stack-protector to the build. So it should work now. get
from svn...



On Jan 31, 5:37 pm, "Vlad Skarzhevskyy" <skarzhevs...@gmail.com>
wrote:

[Vlad Skarzhevskyy]

Yes the record size has been committed before the -fno-stack-protector changes.
Tested and it should produce the Exception if there are too many data elements.
I did not test the size of each data element. May be this is the case.

I need a complete file system independent example to reproduce the problem.

I tested like this: But only on Fedora 7

----------------
DataElement seqLong = new DataElement(DataElement.DATSEQ);
for (int i = 0; i < 100; i++) {
seqLong.addElement(new DataElement(DataElement.STRING,
"BlueCove-long-seq " + i));
}
record.setAttributeValue(IMAGES_NAMES_ATTRIBUTE_ID, seqLong);
---------------

--
Vlad

[somatik]

your test code throws the correct exception on my side so it will be
something else that is causing the stack smash

I've been doing some tests and it seems that how bigger the strings
i'm adding how faster the error occurs, there must be some kind of
size limit hit there. Maybe it's caused by the way I add items
(requesting record, adding string to attribute, updating record,
requesting record, ....)

using the following ocde I was able to generate a cash file

String item;
int total = 0;
for (int i =0;i<100;i++){
item = "aa" + i;
total += item.length();
System.out.println("trying: " + total);
DataElement base =
record.getAttributeValue(IMAGES_NAMES_ATTRIBUTE_ID);
DataElement de = new DataElement(DataElement.STRING,
item);
base.addElement(de);
record.setAttributeValue(IMAGES_NAMES_ATTRIBUTE_ID,
base);

System.out.println("total: " + total);
}
// 182, 175, 162, 146
try {
localDevice.updateRecord(record);
} catch (ServiceRegistrationException ex) {

Logger.getLogger(VodtecServer.class.getName()).log(Level.SEVERE, null,
ex);
}

output:

#
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x8ff18f82, pid=10983, tid=2415917968
#
# Java VM: Java HotSpot(TM) Server VM (1.6.0_03-b05 mixed mode)
# Problematic frame:
# C [libbluetooth.so.2+0xbf82] sdp_append_to_buf+0x22
#
# An error report file with more information is saved as
hs_err_pid10983.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#

I mailed the logfile

and something else:

just a remark, might be better to add a message to that
classcastexception so it is clear why it happens (like the javadoc)
System.out.println(de.getSize());
java.lang.ClassCastException
at javax.bluetooth.DataElement.getSize(DataElement.java:562)

On Feb 1, 4:38 pm, "Vlad Skarzhevskyy" <skarzhevs...@gmail.com> wrote:
> Yes the record size has been committed before the -fno-stack-protector changes.
> Tested and it should produce the Exception if there are too many data elements.
> I did not test the size of each data element. May be this is the case.
>
> I need a complete file system independent example to reproduce the problem.
>
> I tested like this: But only on Fedora 7
>
> ----------------
> DataElement seqLong = new DataElement(DataElement.DATSEQ);
> for (int i = 0; i < 100; i++) {
> seqLong.addElement(new DataElement(DataElement.STRING,
> "BlueCove-long-seq " + i));}
>
> record.setAttributeValue(IMAGES_NAMES_ATTRIBUTE_ID, seqLong);
> ---------------
>

[Vlad Skarzhevskyy]

Apparently this is error in bluez-libs apparently each SEQ size is
limited to 256 bytes.
You may submit this bug to bluez. See function sdp_append_to_pdu in sdp.c