8.6b1.1 - failed to create a valid string rep
neuro...@gmail.com
I've just checked out the current source of 8.6b1.1 and tried it on a
daemon I run on FreeBSD which has been running ok on 8.6a0
The process crashes with the following:
UpdateStringProc for type 'string' failed to create a valid string rep
Abort (core dumped)
It's a multithreaded app - so it might be a little tricky to find
exactly what triggers this.. any pointers?
Thanks,
Julian
Don Porter
> Hi,
>
> I've just checked out the current source of 8.6b1.1 and tried it on a
> daemon I run on FreeBSD which has been running ok on 8.6a0
>
>
> The process crashes with the following:
>
> UpdateStringProc for type 'string' failed to create a valid string rep
> Abort (core dumped)
That's a new check that the contract of the UpdateStringProc()
is being met. It's possible your program has been silently failing
in this way all the time, and the only thing new is now you're being
informed about it.
Got any stack trace information at all?
How aggressively have you customized things? Can we assume the
type 'string' is the one provided by Tcl, or is it a custom replacement
in your program?
> It's a multithreaded app - so it might be a little tricky to find
> exactly what triggers this.. any pointers?
>
> Thanks,
> Julian
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Don Porter
> The process crashes with the following:
>
> UpdateStringProc for type 'string' failed to create a valid string rep
> Abort (core dumped)
Can you check whether the Tcl_Obj triggering this panic is an empty
string in "pure unicode" form? There's a gap in UpdateStringOfString
not checking for that case, but all the paths which should be able to
create it appear to have string rep creation covered.
It would be best to get this reported in the actual Tcl Bug Tracker
at Sourceforge, and include whatever you can about the value that
triggers the panic. Its contents and history.
JMN
> neuronst...@gmail.com wrote:
> > Hi,
>
> > I've just checked out the current source of 8.6b1.1 and tried it on a
> > daemon I run on FreeBSD which has been running ok on 8.6a0
>
> > The process crashes with the following:
>
> > UpdateStringProc for type 'string' failed to create a valid string rep
> > Abort (core dumped)
>
> That's a new check that the contract of the UpdateStringProc()
> is being met. It's possible your program has been silently failing
> in this way all the time, and the only thing new is now you're being
> informed about it.
>
> Got any stack trace information at all?
>
> How aggressively have you customized things? Can we assume the
> type 'string' is the one provided by Tcl, or is it a custom replacement
> in your program?
>
> > It's a multithreaded app - so it might be a little tricky to find
> > exactly what triggers this.. any pointers?
>
> > Thanks,
> > Julian
Hi Don,
It's a pure Tcl app - but uses a few extensions such as sqlite, tdom..
so no - I haven't done anything radical that I know of.
Sorry - no stack trace info - I'm not familiar with producing it.
Actually - my claim that it had been running ok wasn't quite true - as
it seemed to have a memory leak before and died after a few hours,
so perhaps that is related.
It appears to be occuring on an expression using 'ni' and a string
which was retrieved using tsv::get.
ie the program crashes on the 'if' line below.
set streams_on_thisthread [tsv::get t_
$allocated_tid accounts_on_thread]
if {"$accountid_with_pending/$logtype" ni
$streams_on_thisthread} {
tsv::lappend t_$allocated_tid
accounts_on_thread "$accountid_with_pending/$logtype"
}
I did also check out and build the thread extension at the same time.
JN
JMN
> neuronst...@gmail.com wrote:
> > The process crashes with the following:
>
> > UpdateStringProc for type 'string' failed to create a valid string rep
> > Abort (core dumped)
>
> Can you check whether the Tcl_Obj triggering this panic is an empty
> string in "pure unicode" form? There's a gap in UpdateStringOfString
> not checking for that case, but all the paths which should be able to
> create it appear to have string rep creation covered.
>
> It would be best to get this reported in the actual Tcl Bug Tracker
> at Sourceforge, and include whatever you can about the value that
> triggers the panic. Its contents and history.
>
I'm not sure how to directly work out what's in the value at this
stage.
after the line:
set streams_on_thisthread [tsv::get t_$allocated_tid
accounts_on_thread]
it turns out that attempting to puts $streams_on_thisthread triggers
the crash.. which I guess isn't surprising.
As far as I can tell - the value should be an empty list at this stage
of the program's run.
The line where the value is set is:
tsv::array set t_$tid [list job_count 0 thread_started [clock
seconds] accounts_on_thread [list]]
I also tried:
tsv::array set t_$tid [list job_count 0 thread_started [clock
seconds] accounts_on_thread ""]
Interestingly.. by putting some junk in there - the crash is avoided.
e.g
tsv::array set t_$tid [list job_count 0 thread_started [clock
seconds] accounts_on_thread "spud"]
A space also works.
JN
Alexandre Ferrieux
I would try to look at the offending string object's internal fields,
eg with the Tweezer extension or similar (eg patch at
https://sourceforge.net/tracker/?func=detail&aid=1980917&group_id=10894&atid=310894
). For example:
- is the refcount >1 ?
- is the string rep lost at some time ?
- does the int rep change over time ?
-Alex
JMN
wrote:
> ). For example:
>
> - is the refcount >1 ?
> - is the string rep lost at some time ?
> - does the int rep change over time ?
>
>
> - Show quoted text -
Hmm.. not sure if I'm applying the patch correctly.
It said it succeeded, but make gives me:
In file included from /usr/local/buildtcl/8.6b1.1/tcl/generic/
regcustom.h:33,
from /usr/local/buildtcl/8.6b1.1/tcl/generic/
regguts.h:36,
from /usr/local/buildtcl/8.6b1.1/tcl/generic/
regcomp.c:33:
/usr/local/buildtcl/8.6b1.1/tcl/generic/tclInt.h:2756: error: storage
class specified for parameter `Tcl_DebugObjObjCmd'
/usr/local/buildtcl/8.6b1.1/tcl/generic/tclInt.h:2756: warning:
`__visibility__' attribute ignored
/usr/local/buildtcl/8.6b1.1/tcl/generic/tclInt.h:2752: error:
parameter "interp" has just a forward declaration
/usr/local/buildtcl/8.6b1.1/tcl/generic/tclInt.h:2752: error:
parameter "listPtr" has just a forward declaration
/usr/local/buildtcl/8.6b1.1/tcl/generic/tclInt.h:2756: error:
parameter "Tcl_DebugObjObjCmd" has just a forward declaration
*** Error code 1
JN
JMN
> ). For example:
>
> - is the refcount >1 ?
> - is the string rep lost at some time ?
> - does the int rep change over time ?
>
>
> - Show quoted text -
tweezer type: string
tweezer refcount: 2
string length: 0
string bytelength triggers the crash.
Attempting to tweezer shimmer the value to another type such as list
or bytearray also triggers the crash.
Nothing has been written to that element of the array since it was
initially setup using:
tsv::set t_$tid accounts_on_thread [list]
(I split up the previous 'tsv::array set' to try to isolate it)
tsv::set t_$tid accounts_on_thread ""
also has the problem
tsv::set t_$tid accounts_on_thread " "
Is a workaround that fixes my app.
I've been unable to produce a simple script which demonstrates the
crash.
JN
Alexandre Ferrieux
Oops, I realize this was a fragile diff. I have now updated it to a
more robust one (cvs diff -u), relative to the current HEAD. Thanks
for the feedback.
-Alex
Alexandre Ferrieux
The main difference between "" and " " is that "" is likely to be a
more heavily shared literal.
So I would predict that obtaining a fresh, unshared empty string by
replacing "" with (e.g.) [list], would avoid the bug too.
Now please follow Don's advice and open a bug ticket like "TSV
misbehaves with shared literals". We'll follow up from there.
-Alex
Bruce Hartweg
except that is what his original code was doing in the first place
> Now please follow Don's advice and open a bug ticket like "TSV
> misbehaves with shared literals". We'll follow up from there.
>
definitely file the bug on tsv behaviors, but I would jump to the conclusion
that it is only shared literals only.
Bruce
Alexandre Ferrieux
Oops :-}
> > Now please follow Don's advice and open a bug ticket like "TSV
> > misbehaves with shared literals". We'll follow up from there.
>
> definitely file the bug on tsv behaviors, but I would jump to the conclusion
> that it is only shared literals only.
However, further investigation shows that [list] and "" in procs get
compiled to the same, shared literal.
Try [string range a 0 -1], just tested, it breaks its ties to the
literal pool.
-Alex
JMN
Thanks.. tried your suggesion of [string range a 0 -1] and the bug
does not occur with that value.
It's also absent with [string range "" 0 0]
Bug ticket # 2803109 opened.
JN
Alexandre Ferrieux
A quick update: Don and Joe (Mistachkin) nailed it down. It was/is a
bad interaction between questionable intrep surgery in the Thread
extension, and a recent, unwanted restriction on UpdateStringOfString
in the core. Patch including test case in the oven.
-Alex