#12 Crash when creating new database w/NO Frontier.root

Configuration: Mac OS X 10.3.x. Frontier 10.0a4 built with Xcode or
CW Pro 8 from current sources (01 Dec 04). Existing Frontier.root
(from minimal install) with minor changes; most recently addition
of mainResponder.root install. NOTE: the application is in a
different folder from that of the rest of Frontier, and upon launch of
the application, you are prompted to locate a Frontier root.

Steps to reproduce :

1) Launch the Frontier application.
2) When prompted for a Frontier root, click Cancel.
3) Choose "New Database" from the "File" menu.
4) Navigate to some folder (I used the same folder where the rest
of the Frontier is located), and name the new database.
5) While creating the database, Frontier will crash because of a nil
handle (htable) :

Host Name: twinpeaks.local
Date/Time: 2004-12-02 01:00:48 -0800
OS Version: 10.3.3 (Build 7F44)
Report Version: 2

Command: UserLand Frontier™ (dbg)
Path: /Volumes/TwinPeaks/Projects/FrontierKernel_10.0/
build_CWPro8/Frontier_OSX_Debug/UserLand Frontier™ (dbg)
Version: ??? (???)
PID: 421
Thread: 0

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0 UserLand Frontier™ (dbg) 0x004c9574 chainhashtable +
0x14
1 UserLand Frontier™ (dbg) 0x004dd464
langpushscopechain + 0x24
2 UserLand Frontier™ (dbg) 0x00541b74 tablepushcontext
+ 0x44
3 UserLand Frontier™ (dbg) 0x005392a0 tablegetcellstring
+ 0x130
4 UserLand Frontier™ (dbg) 0x0053940c
tablegetmaxcolwidthvisit + 0x2c
5 UserLand Frontier™ (dbg) 0x00539514
tablegetmaxwidthvisit + 0x44
6 UserLand Frontier™ (dbg) 0x004f0698 opsiblingvisiter +
0xa8
7 UserLand Frontier™ (dbg) 0x00539644
tablegetoutlinesize + 0xd4
8 UserLand Frontier™ (dbg) 0x0053e704
tablerecalccolwidths + 0xd4
9 UserLand Frontier™ (dbg) 0x0053b4a0
tableresetformatsrects + 0x50
10 UserLand Frontier™ (dbg) 0x0053b648
tableverbsetupdisplay + 0x118
11 UserLand Frontier™ (dbg) 0x00466780
ccwindowsetuptableview + 0x70
12 UserLand Frontier™ (dbg) 0x0046692c
ccwindownewrecord + 0x2c
13 UserLand Frontier™ (dbg) 0x0051d13c shellnewfile +
0x10c
14 UserLand Frontier™ (dbg) 0x0051d28c shellnew + 0x9c
15 UserLand Frontier™ (dbg) 0x0046a340
ccnewobjectcommand + 0x60
16 UserLand Frontier™ (dbg) 0x0046a454 ccmenuroutine +
0x64
17 UserLand Frontier™ (dbg) 0x0051e3c4
shellcallmenuhooks + 0x44
18 UserLand Frontier™ (dbg) 0x00521320 shellhandlemenu
+ 0x40
19 UserLand Frontier™ (dbg) 0x005221d8
shellhandlemouse + 0x278
20 UserLand Frontier™ (dbg) 0x00518280 shellhandleevent
+ 0x80
21 UserLand Frontier™ (dbg) 0x00518c6c shelleventloop +
0x4c
22 UserLand Frontier™ (dbg) 0x00518eb4
shellmaineventloop + 0x14
23 UserLand Frontier™ (dbg) 0x0044c0a8 main + 0x58

Thread 1:
0 libSystem.B.dylib 0x90018ce8
semaphore_timedwait_signal_trap + 0x8
1 libSystem.B.dylib 0x9000e888 _pthread_cond_wait
+ 0x268
2 ...ple.CoreServices.CarbonCore 0x90295cdc MPWaitOnQueue
+ 0xe0
3 com.apple.DesktopServices 0x90918f8c TNodeSyncTask::
SyncTaskProc(void*) + 0x70
4 ...ple.CoreServices.CarbonCore 0x902c6dc0
PrivateMPEntryPoint + 0x4c
5 libSystem.B.dylib 0x900247e8 _pthread_body +
0x28

PPC Thread State:
srr0: 0x004c9574 srr1: 0x0200f030 vrsave:
0x00000000
cr: 0x44002222 xer: 0x00000006 lr: 0x004dd464 ctr:
0x90001c20
r0: 0x00000000 r1: 0xbfffe940 r2: 0x000be000 r3:
0x000cf6d8
r4: 0x003339b0 r5: 0x003339b0 r6: 0x00000000 r7:
0x00010001
r8: 0x00000000 r9: 0x08100001 r10: 0x00000001 r11:
0x00000007
r12: 0x90001c20 r13: 0x00000000 r14: 0x00000000 r15:
0x00000000
r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19:
0x00000000
r20: 0xbffffe0c r21: 0xffffffff r22: 0x00000162 r23:
0x00000000
r24: 0x000aeaf0 r25: 0x00000002 r26: 0xbffff004 r27:
0x000aeafc
r28: 0x00000001 r29: 0x000aeaec r30: 0x000aeafc r31:
0x00000000

Binary Images Description:
0x1000 - 0x9fff UserLand Frontier™ (dbg) /Volumes/
TwinPeaks/Projects/FrontierKernel_10.0/build_CWPro8/
Frontier_OSX_Debug/UserLand Frontier™ (dbg)

[etc...]

[Anonymous]

Logged In: YES
user_id=225318

I can't reproduce the problem if I run the Frontier application in the same
folder as Frontier.root - i.e. when Frontier.root is not opened on launch it
is possible to cause a crash.

[Andre Radke]

Logged In: YES
user_id=1137587

If Frontier.root isn't open (or if there's not database that has a table
named system at the top-level), roottable will be a nil handle.

In your crash log, langpushscopechain called chainhashtable with
roottable as the parameter. The crash occurred because chainhashtable
dereferenced the nil handle.

Popping out two levels, apparently tablegetcellstring calls
tablepushcontext so it can safely call hashgetvaluestring. The latter
might perform coercions etc. that at the least require a table pushed for
its temp stack.

Maybe if tablepushscopechain is called while roottable == nil, it should
do the same thing it does if (**ht).fllocaltable is true: just push the
current table. tablepopcontext would have to be adapted accordingly.

I don't understand this well enough yet to be certain that this is the
proper solution, but I think it's at least worth investigating.