Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Access violation when device description has no presentation URL
24-08-2011, 09:47 AM
Post: #1
Access violation when device description has no presentation URL
If I use the getAttribute() method of CpDevice to get the "PresentationUrl" attribute (as described under "Web UI" in the Control Point Stack document), I get an access violation if there isn't a <presentationURL> element in the device description XML file. This is valid according to the UPnP spec and will be true for devices created using ohNet without passing a resource manager for UI files. The error is as follows:

#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d9dbd86, pid=5492, tid=7380
#
# JRE version: 6.0_17-b04
# Java VM: Java HotSpot™ Client VM (14.3-b01 mixed mode, sharing windows-x86
)
# Problematic frame:
# V [jvm.dll+0x1dbd86]
#
# An error report file with more information is saved as:
# F:\jm1\hs_err_pid5492.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#

It seems that the code in DeviceXml::GetPresentationUrl doesn't handle the possibility that the device description XML document might not contain a <presentationURL> element.
Find all posts by this user
24-08-2011, 02:45 PM
Post: #2
RE: Access violation when device description has no presentation URL
Thank you for reporting this. We're currently looking into the problem to identify the cause of the issue and get a fix in place.
Find all posts by this user
25-08-2011, 08:29 AM
Post: #3
RE: Access violation when device description has no presentation URL
The source of the problem was in the JNI code for CpDevice. The native code was assuming the attribute value pointer would be pointing to NULL if no attribute was found, which the JNI call for creating the return String would have handled correctly. However, the compiler sets the value of uninitialised variables to 0xCCCCCCCC in debug mode, resulting in the JNI call for allocating the String to crash by trying to access an invalid memory location.

This has been corrected by the JNI code explicitly checking the return status of CpDeviceCGetAttribute().

While fixing this bug, I decided to improve the signature of the getAttribute() method from:

Code:
boolean getAttribute(String aKey, String[] aValue)

to

Code:
CpAttribute getAttribute(String aKey)

The method now takes a single String as the key of the desired attribute and returns a CpAttribute object. The CpAttribute object provides accessors allowing retrieval of the name of the attribute queried for, whether the named attribute was available, and the value of the named attribute.

These changes are in the repository and should be pushed out in the next couple of days.
Find all posts by this user


Forum Jump: