axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stadelmann Josef" <josef.stadelm...@axa-winterthur.ch>
Subject AW: AW: execute axiom_document_free(om_document, env); // and my hash_table key/val pairs are gone
Date Wed, 16 Jan 2008 08:52:04 GMT


-----Urspr√ľngliche Nachricht-----
Von: Senaka Fernando [mailto:senaka@wso2.com]
Gesendet: Dienstag, 15. Januar 2008 18:59
An: Apache AXIS C User List
Cc: axis-c-dev@ws.apache.org
Betreff: Re: AW: execute axiom_document_free(om_document, env); // and
my hash_table key/val pairs are gone


Hi Josef,

The builder & document logic is as follows. The document will always have
a builder and the builder is responsible for creating the document. That
is why it doesn't make sense to free only the document. Reconstructing a
document would involve reconstructing a builder.

It would be better if you could attach the stack trace from your debugger
to diagnose the exact problem, but as far as I know, when you create a
copy of your hash table, the values inside it are simply passed as shallow
copies. That means, your duplicated string resides on the heap and the
hash will have a reference. When you copy your hash, the old as well as
the new one will have the same reference. Then, when you free one, the
other would rather be having a dangling pointer.

The workaround is to change the way you duplicate your hash and get onto
safe grounds. You'd create your hash copy from scratch and iterate through
your original hash and add element by element to the new hash. You can
then do the duplication of strings and create deep copies. This can be
sort of a tedious process. You can get help by reading through the hash.c
source file and see how the hash is copied.

There might not be a bug in the existing implementation in terms of the
way the hashes are copied, because we can't force a user to always
allocate objects on the heap because shallow copies are much faster. Thus,
if a user wishes to do heap allocations and at the same time to duplicate
hashes, he will rather have to override the default behavior.

I believe this might solve your issue. But, I can't guarantee as I have
not seen the exact stack trace or the point at which it breaks.


++> Hi Fernando, 
you'r absolut correct, I went into axutil_hash code and it is as you say;
copy a hash table is not a deep copy but a shalow copy and dangling is very
likely to occure with multiple hash tables; 

maybe we have some day axutil_hash_copy_deep() to overcome such problems. 
It is also nonsens from a OO point of view, given a hash_table is beeing 
seen as an instance of an class in which case freeing one hash obj
should/would not touche the other's hash obj's strings (key/val's)

Thanks for the fine answer, I have my problem under control now, and it
is as it is, if you are aware about something (say if it is documented)
best by example code which did not just run throug an editor, then your
most of the time fine. But thanks again.

Josef


Hi Devs,

Please correct me if this should not be the desired behavior. And, if it
is not, this is invariably a bug in the way we copy hashes. Also, please
note that it is documented that axutil_hash_copy() creates a shallow copy.
And, I have assumed that the documentation justifies the logic I speak of.

However, I believe that even if this logic is justifiable it is strongly
recommended that we should introduce another method
axutil_hash_copy_deep() that does a deep copy instead of a shallow copy.
What do you say?

Regards,
Senaka

> Your call correct, it works now but shows a new problem, that of
> freeing two of the 4 hash tables later.
>
> freeing the om_document with
>     axiom_stax_builder_free(om_builder,env);
> seams to work,
>
>
> But freeing a builder when you think you have to free the om_document
> is not so obvious; but you are righth the creator of my om_document
> is the axiom_stax_builder with its get_document.
>
> However this allone does not solve the problem. They still exists.
>
> Until one really does a
>
> 	fldval = (a *) AXIS2_MALLOC(env->allocator, sizeof(a));
>       fldval->value = axutil_strdup(env,getFLDVAL(ele, env));
>       fldnam =        axutil_strdup(env,getFLDNAM(ele, env));
>
> and used the axutil_strdup function; fldval and fldnam are then
> added to the hash tables and I just hope that freeing the hash
> tables deallocates this string space too;
>
> Here I have my doubts because when I do
>
> 	axutil_hash_free(htwsinp,env);
> 	axutil_hash_free(htwsold,env);
> 	//axutil_hash_free(htGWKSP,env);
> 	//axutil_hash_free(htwsout,env);
>
>
> only htwsinp and htwsold can bee freed, while htGWKSP and htwsout
> result in a exception asking me to break or continue in VS 2005
>
> So please here is the code used to make htGWKSP
>
> /**
> 	puts htwsinp hash table into htGWKSP, does like obbput in CORBA world
> 	the ponter to the golbal hash table htGWKSP is updated
> **/
> axis2_bool_t AXIS2_CALL
> axawl_put(const axutil_hash_t *htwsinp,
> 		  const axutil_env_t *env,
> 		  const axutil_hash_t **pphtGWKSP)		//!< load Spin elements into global
> workspace
> {
> 	axutil_hash_t *htGWKSP = NULL;
>     axutil_hash_index_t *hi;
>
>     const void *key = NULL;
>     void *val = NULL;
>
> 	htGWKSP = *pphtGWKSP;
> 	if (htGWKSP)
> 		axutil_hash_free(htGWKSP,env);
>
> 	htGWKSP = axutil_hash_copy(htwsinp, env);
>     printf("\n\nDump htGWKSP - a  copy    of htwsinp to htGWKSP - the
> traditional obbput()");
>     AXIS2_LOG_DEBUG(env->log, AXIS2_LOG_SI, "%s",
>            "\n\nDump htGWKSP - a  copy    of htwsinp to htGWKSP - the
> traditional obbput()");
>     for (hi = axutil_hash_first(htwsinp, env); hi; hi =
> axutil_hash_next(env, hi)) {
>         axutil_hash_this(hi, &key, NULL, &val);
>         printf("\nkey\t: %s", key);
>         printf("\tval\t: %s", ((a *) val)->value);
>         AXIS2_LOG_DEBUG(env->log, AXIS2_LOG_SI, "%s", key);
>         AXIS2_LOG_DEBUG(env->log, AXIS2_LOG_SI, "%s", ((a *) val)->value);
>     }
> 	(*pphtGWKSP) = htGWKSP;
> 	return AXIS2_SUCCESS;
> }
>
>
> Now tell me why I can not use
>
> 	axutil_hash_free(htGWKSP,env);
>
> without getting an error raised?
>
> And the same is true for htwsout which is a copy of htGWKSP before we
> return to the caller.
> htwsout must be freed after reconstructing the AXIOM document and then
> serializing it into
> the payload string to be returned from my SPg-Legacy.c server to its
> client through axis2.
>
> Thanks and regards
> Josef.Stadelmann@
> axa-winterthur.ch
>
>
> -----Urspr√ľngliche Nachricht-----
> Von: Samisa Abeysinghe [mailto:samisa@wso2.com]
> Gesendet: Dienstag, 15. Januar 2008 15:52
> An: Apache AXIS C User List
> Betreff: Re: execute axiom_document_free(om_document, env); // and my
> hash_table key/val pairs are gone
>
>
> Senaka Fernando wrote:
>> 2. Consider duplicating the strings before copying to (or from) your
>> hash.
>> You can use axutil_strdup() for this purpose.
>>
>
> Yes, this may solve your problems. I skimmed through the code given, and
> it looks to me you are using the shallow copies returned by the OM
> element accessor methods and store them in hashes without duplicating
> them.
>
> Thanks,
> Samisa...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-user-help@ws.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org


Mime
View raw message