×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Last week, it wasn't throwing an exception on the V6 box if *any* memory
manager is explicitly in place, even the default, even if I were to set
QIBM_MALLOC_TYPE to some nonsense value.
NOW, it's throwing an exception with the debug memory manager in place.
And I have a stack dump, generated by the debug memory manager
(irrelevant columns and extra space squeezed out in hopes of keeping it
from being mangled):
MODULE NAME PROCEDURE STATEMENT#
QC2ALLOC _C dump stack 32
QC2ALLOC send_message__FiPvUi 62
QC2ALLOC send_C2M1212__FPvUi 2
QC2ALLOC do_free_debug__FPv 15
QSOGSKSY gsk_attribute_get_cert_info 1085
COMMSSLR4 SSL_DEBUG_CERT_INFO 6250
COMMSSLR4 COMMSSL_UPGRADE 5199
HTTPAPIR4 HTTP_PERSIST_OPEN 6294
HTTPAPIR4 HTTP_URL_GET_RAW 5697
GEOLOOKUP GEOCODE 3647
GEOLOOKUP GEOLOOKUP 3508
GEOLOOKUP _QRNP_PEP_GEOLOOKUP
Does this tell us anything? The "SSL_DEBUG_CERT_INFO" suggests that
maybe my hypothesis about the Google web service SSL/TLS negotiations to
get something a V6 box can handle are too lengthy, and that I can
therefore, with essentially zero likelihood of this application ever
being run on a V6 box in the real world, ignore the problem.
--
JHHL
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact
[javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.