[fpc-devel] Unicodestring branch, please test and help fixing

[Florian Klaempfl]

Martin Schreiber schrieb:
> On Saturday 30 August 2008 13.37:42 Florian Klaempfl wrote:
>> I've continued to work on support of an unicodestring type in fpc. It's
>> currently in an svn branch at:
>> http://svn.freepascal.org/svn/fpc/branches/unicodestring
>> and will be merged later to trunk. The unicodestring type is a ref.
>> counted utf-16 string. On non-windows, widestring is mapped to this
>> type. If you're interested in unicode support please test, give feedback
>> here and submit fixes.
>>
> 
> I have a crash in MSEide startup in a procedure finalization section:
> "
> #0  77892373 :0 ??()
> #1  0082CDF4 :0 U_SYSTEM_ENTRYINFORMATION()
> #2  03B7FB2C :0 ??()
> #3  03B7FAAC :0 ??()
> #4  03C22C1C :0 ??()
> #5  0082D9F4 :0 U_SYSTEM_FREELISTS()
> #6  03B7F874 :0 ??()
> #7  0040F5EB heap.inc:1127 SYSFREEMEM(P=0x0)
> #8  778922F8 heap.inc:0 ??()
> #9  0082E500 heap.inc:0 U_HEAPTRC_OWNFILE()
> #10  00410482 systhrd.inc:300 SYSENTERCRITICALSECTION(CS=void)
> #11  0040FE94 thread.inc:190 ENTERCRITICALSECTION(CS={DEBUGINFO = 0x0, 
> LOCKCOUNT = 1, RECURSIONCOUNT = 0, OWNINGTHREAD = 0, LOCKSEMAPHORE = 812, 
> SPINCOUNT = 0})
> #12  00414571 heaptrc.pp:666 TRACEFREEMEMSIZE(P=0x6d11b8, SIZE=0)
> #13  004146BB heaptrc.pp:722 TRACEFREEMEM(P=0x6d11b8)
> #14  0040E404 heap.inc:275 FREEMEM(P=0x6d11b8)
> #15  004093FA ustrings.inc:179 DISPOSEUNICODESTRING(S=0x6d11b8)
> #16  0040947D ustrings.inc:206 fpc_unicodestr_decr_ref(S=0x6d11b8)
> #17  004A9B1C msesysintf.pas:306 WINFILEPATH(DIRNAME=0x0, FILENAME=0x6d11b8, 
> result=0x3c22fa8)
> #18  004AB63F msesysintf.pas:1436 SYS_OPENDIRSTREAM(STREAM={INFOLEVEL = 
> FIL_NAME, DIRNAME = 0x3c23148, MASK = 0x3b7faa0, INCLUDE = [FA_ALL], EXCLUDE 
> = [], PLATFORMDATA = {0, 208983208, 1, 4294967295, 0, 0, 0, 0}})
> #19  004B5BB2 msefileutils.pas:640 SEARCHFILE(AFILENAME=0xc7a07b0, 
> ADIRNAME=0x3c22e08, result=0x0)
> #20  004B5DED msefileutils.pas:671 SEARCHFILE(AFILENAME=0x6bf2f8, 
> ADIRNAMES=0x3c22ed8, highADIRNAMES=0, result=0x0)
> #21  004B5F9C msefileutils.pas:698 FINDFILE(FILENAME=0x6bf2f8, 
> DIRNAMES=0x3c22ed8, PATH=0x0, highDIRNAMES=0)
> #22  004C03E1 msestatfile.pas:244 TSTATFILE__READSTAT(STREAM=0x0, 
> this=0x3c6b918)
> #23  00453CF8 main.pas:1514 TMAINFO__MAINONLOADED(SENDER=0x3c03d40, 
> this=0x3c03d40)
> #24  0050A717 mseforms.pas:854 
> TCUSTOMMSEFORM__DOEVENTLOOPSTART(this=0x3c03d40)
> #25  0050A763 mseforms.pas:863 TCUSTOMMSEFORM__RECEIVEEVENT(EVENT=0xc7016f8, 
> this=0x3c03d40)
> #26  0048CA3A mseevent.pas:213 TOBJECTEVENT__DELIVER(this=0xc7016f8)
> #27  0042E7D0 msegui.pas:12666 
> TINTERNALAPPLICATION__EVENTLOOP(AMODALWINDOW=0x0, ONCE=false, this=0x3bd9460)
> #28  0042F52C msegui.pas:13063 TINTERNALAPPLICATION__DOEVENTLOOP(ONCE=false, 
> this=0x3bd9460)
> #29  0048B3F8 mseapplication.pas:1132 TCUSTOMAPPLICATION__RUN(this=0x3bd9460)
> #30  004025D1 mseide.pas:59 main()
> "
> I could not find a simple program to demonstrate the failure. Something 
> strange is that the following procedure calls fpc_WideStr_Decr_Ref in 
> finalization section:
> "
> const
>  quotechar = unicodechar('"');
> 
> procedure requote(var path: unicodestring; const newvalue: unicodestring);
> begin
>  if punicodechar(path)^ = quotechar then begin
>   path:= quotechar + newvalue;
>  end
>  else begin
>   path:= newvalue;
>  end;
> end;
> "
> I saw that you merged unicodestring to trunk. Should I test with trunk instead 
> of unicodestring branch?

Yes. Unicodestring branch is closed.