in reply to Modification of read-only value
Switch from JSON (which defaults to thunking to JSON::XS) to JSON::PP and watch this mysterious behavior mysteriously disappear.
No, I can't guarantee such results. But my batting average on that prediction is actually pretty high so far.
- tye
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Modification of read-only value (XS--)
by Tanktalus (Canon) on Jun 14, 2011 at 05:04 UTC | |
Unfortunately, this one isn't improving your batting average :-) Or is this not the mysterious behaviour you're referring to, as I did have two mysterious behaviours to deal with here? Looks like I'm going to have to keep with my custom JSON-ish output until I find a better dumper :-) (Which is getting woefully off-topic for this thread, but I'll point out that I like the conciseness of JSON, but need some more flexibility, e.g., dumping stuff other than scalars, arrays, hashes, and nulls, but at the same time, not dumping all the contents of every object like Data::Dump(er) are wont to do.) However, I don't think this is related to my original problem where I'm not using JSON::XS, either, but my own pseudo-JSON-ish generator. The read-only error crops up in that generator code (thus why it shows up in my original node), but it's called from the signal handling code, where I'm suspicious the real error comes from. | [reply] [d/l] |
by tye (Sage) on Jun 14, 2011 at 06:25 UTC | |
However, I don't think this is related to my original problem where I'm not using JSON::XS, either Oh, the big block of code is for a separate process than the one getting the mysterious error referenced in the node title (modification of read-only value) ? The only code you give us for the process that experiences the in-title error is just the one subroutine? So the vast majority of the write-up is about something not alluded to in the title? I guess you seriously and thoroughly buried the lead. You lost me in the rambling about political problems and making excuses for not doing some things some other way and described some stuff that didn't make much sense to me on first reading but then said that it was the point at which the original error happens and so I didn't think it was a separate problem, just more explanation about where you see the one problem. So I didn't try to re-read it and make sense of it all since the in-title error (that you described quite nicely) is not something that happens because of anything you do in Perl code. It happens because somebody did something stupid or wrong in C code. You either have found a bug in Perl or you have found a bug in a module that uses XS code. The odds between those two buckets are very, very lopsided. (Or you have disabled "safe signal handlers" without doing significant amounts of work to compensate for each invocation of an unsafe signal handler having a 10% chance of just making Perl marginally insane -- but I see no mention of "safe" so I assume that isn't the case.) Find the module that you are using that uses the most XS code and replace it with something else. You'll have pretty good odds (IME) of the (in-title) error going away. So, what is the huge block of code that you appear to never describe beyond calling it "the stuff below"? I have no idea at this point. I (rather blithely, it appears) assumed that it was code that actually had something to do with the error in the title. If it isn't code that actually reproduces the error, I thought it would be rather clearly labeled as not such. As for using JSON for more arbitrary data, we wrote a data sanitizer that replaces objects that define stringification with their stringified value, replaces code references with { CODE => getNameOfSubroutine($ref) }, replaces scalar references with { SCALAR => $$ref }, etc. so that we get the important information and not lots of noise and just pass that in to be formatted as JSON. Of course, one of the really nice things about the JSON format is that it is so extremely simple. Rolling your own version of it shouldn't take more than a couple of dozen of lines of code so one shouldn't feel too shy about doing that when there is reason to. - tye | [reply] [d/l] [select] |