Crash on AddRecord
Francois Van Lerberghe
fvanlerberghe at freegates.be
Sat Apr 21 04:52:40 CDT 2012
Mmmh, I've talk too fast.
With V4RB v4.8.1, no more crash
replacing the LOCATE() function with some IF().
With V4RB v4.9.1 or v4.9, the crash is always there,
on the very same record. This is the crash log :
0 libvkernel_fat_release.dylib 0x1917d7ee
fbl::vu_strcoll_uu_icu(unsigned short const*, int, unsigned short const*,
int, fbl::I_Collator*) + 130
1 libvkernel_fat_release.dylib 0x190b6d54
fbl::ENode_Pred_Equal_Str::long_val(unsigned int) + 228
2 libvkernel_fat_release.dylib 0x190b6104
fbl::ENode_Pred_CmpOp::llong_val(unsigned int) + 24
3 libvkernel_fat_release.dylib 0x190a4d07
fbl::ENode_Func_If::llong_val(unsigned int) + 31
4 libvkernel_fat_release.dylib 0x1916f105
fbl::AssignToValue(fbl::smart_ptr<fbl::I_Value>,
fbl::smart_ptr<fbl::I_ENode>, unsigned int) + 191
5 libvkernel_fat_release.dylib 0x19056703
fbl::Method_SQL::Evaluate(unsigned int, fbl::smart_ptr<fbl::I_Value>) + 221
6 libvkernel_fat_release.dylib 0x19117a71
fbl::policyMethodYes::DoMethod(fbl::FldStorage*, unsigned int,
fbl::I_Value*) + 95
7 libvkernel_fat_release.dylib 0x194007fc
fbl::FldStorageMaster_T<fbl::policyFileNo, fbl::policyNullNo,
fbl::policyMethodYes>::ReadValue(unsigned int, fbl::smart_ptr<fbl::I_Value>)
+ 62
8 libvkernel_fat_release.dylib 0x190f4372
fbl::Field_Imp::ReadValue(unsigned int) + 60
9 libvkernel_fat_release.dylib 0x1913fdb7
fbl::Table::ReEvaluateAllMethods(unsigned int) + 101
10 libvkernel_fat_release.dylib 0x1913fe8c
fbl::Table::AddRecord_WithOut_Triggers_ex() + 156
11 libvkernel_fat_release.dylib 0x1913f101
fbl::Table::AddRecord_WithOut_OnEachStatement_Triggers_ex() + 187
12 libvkernel_fat_release.dylib 0x1913f304 fbl::Table::AddRecord() +
478
13 libvkernel_fat_release.dylib 0x19148b0b
fbl::Table_Indirect::AddRecord() + 229
14 libvkernel_fat_release.dylib 0x19153542
fbl::vsql::Cursor::AddRecord() + 258
15 ..._macho_ub_4_9_1.rbx_0.dylib 0x18dc068a
Cursor_AddRecord(REALobjectStruct*) + 114
With V4RB v5beta, the crash is always there, on the very same record,
but with another crash log :
0 ??? 0000000000 0 + 0
1 libvkernel_fat_release.dylib 0x191e01db
fbl::ENode_Pred_Equal_Str::long_val(unsigned int) + 243
2 libvkernel_fat_release.dylib 0x191de4a2
fbl::ENode_Pred_CmpOp::llong_val(unsigned int) + 24
3 libvkernel_fat_release.dylib 0x191cb096
fbl::ENode_Func_If::llong_val(unsigned int) + 32
4 libvkernel_fat_release.dylib 0x192a9359
fbl::AssignToValue(fbl::smart_ptr<fbl::I_Value>,
fbl::smart_ptr<fbl::I_ENode>, unsigned int) + 278
5 libvkernel_fat_release.dylib 0x19174593
fbl::Method_SQL::Evaluate(unsigned int, fbl::smart_ptr<fbl::I_Value>) + 229
6 libvkernel_fat_release.dylib 0x19248e67
fbl::policyMethodYes::DoMethod(fbl::FldStorage*, unsigned int,
fbl::I_Value*) + 93
7 libvkernel_fat_release.dylib 0x195553bc
fbl::FldStorageMaster_T<fbl::policyFileNo, fbl::policyNullNo,
fbl::policyMethodYes>::ReadValue(unsigned int, fbl::smart_ptr<fbl::I_Value>)
+ 48
8 libvkernel_fat_release.dylib 0x1921c05b
fbl::Field_Imp::ReadValue(unsigned int) + 57
9 libvkernel_fat_release.dylib 0x1927b960
fbl::Table::ReEvaluateAllMethods(unsigned int) + 94
10 libvkernel_fat_release.dylib 0x1927bf28
fbl::Table::AddRecord_WithOut_Triggers_ex() + 102
11 libvkernel_fat_release.dylib 0x1927ba45
fbl::Table::AddRecord_WithOut_OnEachStatement_Triggers_ex() + 171
12 libvkernel_fat_release.dylib 0x19277e80 fbl::Table::AddRecord() +
428
13 libvkernel_fat_release.dylib 0x1927f5e1
fbl::Table_Indirect::AddRecord() + 217
14 libvkernel_fat_release.dylib 0x19289c29
fbl::vsql::Cursor::AddRecord() + 223
15 V4RB_macho_ub_5b.rbx_0.dylib 0x18ed69d2
Cursor_AddRecord(REALobjectStruct*) + 117
I don¹t understand what¹s happening since I use IF() function in many other
tables without exhibit any problem ... for the moment :-(.
François Van Lerberghe
Rue Thier Monty, 15 A
4570 Marchin
Belgique
le 21/04/12 10:15, Francois Van Lerberghe <fvanlerberghe at freegates.be> a
écrit :
> The function LOCATE() seems to be the culprit here. Replacing it with a
> bunch of IF() solve my problem : no more crash.
> I hope that workaround will not decrease too much the speed...
>
> Ruslan, is there another workaround more efficient ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macserve.net/pipermail/valentina/attachments/20120421/9cd04248/attachment-0001.html>
More information about the Valentina
mailing list