Re: Strange HASH(0x2ced735) values

[Superior Shelving]

> On Feb 21, 2017, at 8:34 AM, Uri Guttman  wrote:
> 
> you can't trace it from the value. but you can write code where that value is 
> stuffed into the db and look for a reference vs 1 or a blank. then you can 
> dump the call stack (with caller()) or do other debugging. something is 
> putting a hash reference in there that shouldn't be doing it.

Thanks Uri, but that’s the problem - so far I haven’t been able to tell 
where it’s being generated.  That’s why I was hoping to decode that value.  
Looks like I’ll have to continue searching. :\

Frank
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Strange HASH(0x2ced735) values

[SSC_perl]

> On Feb 21, 2017, at 2:34 PM, Sam  wrote:
> 
> One can also turn on the DBI trace log as well.

Thanks, Sam!  That helped a lot.  Now I know which subs are involved in 
creating the SQL so I’m much closer to tracking this down.

This is why they say that two heads are better than one.  It didn’t 
even occur to me to turn that on.  :\

Frank
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Strange HASH(0x2ced735) values

[Sam]

On 02/21/2017 04:12 PM, David Precious wrote:

On Tue, 21 Feb 2017 09:11:10 -0800
SSC_perl  wrote:


On Feb 21, 2017, at 8:34 AM, Uri Guttman 
wrote:

you can't trace it from the value. but you can write code where
that value is stuffed into the db and look for a reference vs 1 or
a blank. then you can dump the call stack (with caller()) or do
other debugging. something is putting a hash reference in there
that shouldn't be doing it.


Thanks Uri, but that’s the problem - so far I haven’t been
able to tell where it’s being generated.  That’s why I was hoping to
decode that value.  Looks like I’ll have to continue searching. :\


As Uri explained, there's nothing to "decode" - it's just a string
representation, where the value is the memory address that hash had at
the time.

Look at all the places you execute queries; (at least) one of them is
accidentally passing a hashref instead of a scalar value.



One can also turn on the DBI trace log as well. It will show the inserts 
with the data. Of course it won't tell you where it is running from 
code-wise. And it won't help if you can't get the bad values to appear 
on demand either...


--Sam

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Strange HASH(0x2ced735) values

[Uri Guttman]

On 02/21/2017 05:12 PM, David Precious wrote:

On Tue, 21 Feb 2017 09:11:10 -0800
SSC_perl  wrote:


On Feb 21, 2017, at 8:34 AM, Uri Guttman 
wrote:

you can't trace it from the value. but you can write code where
that value is stuffed into the db and look for a reference vs 1 or
a blank. then you can dump the call stack (with caller()) or do
other debugging. something is putting a hash reference in there
that shouldn't be doing it.

Thanks Uri, but that’s the problem - so far I haven’t been
able to tell where it’s being generated.  That’s why I was hoping to
decode that value.  Looks like I’ll have to continue searching. :\

As Uri explained, there's nothing to "decode" - it's just a string
representation, where the value is the memory address that hash had at
the time.

Look at all the places you execute queries; (at least) one of them is
accidentally passing a hashref instead of a scalar value.

that is pretty much my suggestion but you fleshed it out some more. the 
OP needs to find all the related sql inserts/updates and put perl code 
that dumps things if it finds any references (in general you should 
store references into a database - they are nonsense there). look for 
code that uses the table with the field in question and add the checking 
code to that.


uri

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Strange HASH(0x2ced735) values

[David Precious]

On Tue, 21 Feb 2017 09:11:10 -0800
SSC_perl  wrote:

> > On Feb 21, 2017, at 8:34 AM, Uri Guttman 
> > wrote:
> > 
> > you can't trace it from the value. but you can write code where
> > that value is stuffed into the db and look for a reference vs 1 or
> > a blank. then you can dump the call stack (with caller()) or do
> > other debugging. something is putting a hash reference in there
> > that shouldn't be doing it.
> 
>   Thanks Uri, but that’s the problem - so far I haven’t been
> able to tell where it’s being generated.  That’s why I was hoping to
> decode that value.  Looks like I’ll have to continue searching. :\

As Uri explained, there's nothing to "decode" - it's just a string
representation, where the value is the memory address that hash had at
the time.

Look at all the places you execute queries; (at least) one of them is
accidentally passing a hashref instead of a scalar value.

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Strange HASH(0x2ced735) values

[SSC_perl]

> On Feb 21, 2017, at 8:34 AM, Uri Guttman  wrote:
> 
> you can't trace it from the value. but you can write code where that value is 
> stuffed into the db and look for a reference vs 1 or a blank. then you can 
> dump the call stack (with caller()) or do other debugging. something is 
> putting a hash reference in there that shouldn't be doing it.

Thanks Uri, but that’s the problem - so far I haven’t been able to tell 
where it’s being generated.  That’s why I was hoping to decode that value.  
Looks like I’ll have to continue searching. :\

Frank
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Strange HASH(0x2ced735) values

[Uri Guttman]

On 02/21/2017 11:28 AM, SSC_perl wrote:

In a MySQL db I have a `customers` table with a field called `hide`.  
There are some strange values that I’d like to know where they’re coming from.  
In most records `hide` is blank, some others have the value ‘1’, but a handful 
have values like HASH(0x2ced735).
that value is a hash reference converted to a string. the number is the 
actual memory address of that hash and is meaningless at this point if 
the program is finished (likely since you are looking at the db much later).


I take it from what little information I could find, that those are 
%hash values stored in the db.  Unfortunately, I can’t find where they are 
generated from in the script, so I was wondering if there was a way I could 
decipher what’s in those HASH() vales?  Maybe that will help me find the source 
and fix it.
you can't trace it from the value. but you can write code where that 
value is stuffed into the db and look for a reference vs 1 or a blank. 
then you can dump the call stack (with caller()) or do other debugging. 
something is putting a hash reference in there that shouldn't be doing it.


uri

--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Strange HASH(0x2ced735) values

[SSC_perl]

In a MySQL db I have a `customers` table with a field called `hide`.  
There are some strange values that I’d like to know where they’re coming from.  
In most records `hide` is blank, some others have the value ‘1’, but a handful 
have values like HASH(0x2ced735).

I take it from what little information I could find, that those are 
%hash values stored in the db.  Unfortunately, I can’t find where they are 
generated from in the script, so I was wondering if there was a way I could 
decipher what’s in those HASH() vales?  Maybe that will help me find the source 
and fix it.

I know this is not a lot to go on, but any pointers would be a big help.

Thanks,
Frank
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/