Access to CCoeEnv from a secondary thread makes the thread panic with KERN-EXEC 3

when a secondary thread attempts to call a Qt function that has dependency on CCoeEnv, the thread exits with 'Panic KERN-EXEC 3'

steps to reproduce: (sources attached)
1, create a thread.
2, in secondaryThread::run() call a function that has CCoeEnv dependency, like font ascent.
QFontMetrics fm(QFont("Times", 10, QFont::Bold));
qDebug() << "font ascent:" << fm.ascent();

here is the backtrace of the kern-exec 3

DJitCrashHandler::HandleEvent(TKernelEvent EEventKillThread) line 178 + 15 bytes
DKernelEventHandler::Dispatch(void * 0x00000000, void * 0x00a8aae8, TKernelEvent EEventKillThread) line 1670 + 18 bytes
DThread::Exit() line 618 + 12 bytes
DThread::EpocThreadExitHandler(NThread * 0x00a8ada8) line 569
NThreadBase::Exit() line 1057 + 6 bytes
NThreadBase::DoCsFunction() line 643
NFastMutex::Signal() line 109
NKern::ThreadKill(NFastMutex * 0x008a73c8, NThread * 0x00a8ada8) line 1498
DThread::Die(TDesC8 &

{...}, int 3, TExitType EExitPanic) line 693 + 16 bytes
K::PanicCurrentThread(int 3) line 770
K::PanicKernExec(int 3) line 763 + 8 bytes
Exc::Dispatch(void * 0x4ef4f23c) line 212 + 7 bytes
NThread__HandleException(TWin32ExcInfo {...}

) line 287 + 16 bytes
NThread::Exception() line 336
CCoeEnv::ScreenDevice() line 71 + 20 bytes
QS60Data::screenDevice() line 251 + 12 bytes
QFontEngineS60::pointsToPixels(Qt::Orientation Horizontal, float 10.0000) line 204 + 21 bytes
cleanedFontDef(QFontDef &

{...}

) line 343 + 35 bytes
QFontDatabase::load(int 0, QFontPrivate * 0x54d43c98) line 441 + 20 bytes
QFontPrivate::engineForScript(int 0) line 270 + 18 bytes
QFontMetrics::ascent() line 296 + 17 bytes
RenderThread::run() line 15 + 34 bytes
QThreadPrivate::start(void * 0x54cb6e28) line 247
33cb1364()
_E32Startup(void * 0x4ef4fd8c, int 1) line 86 + 9 bytes
DThread::EpocThreadFunction(void * 0x4ef4fd8c) line 69 + 22 bytes
NThread::StartThread(void * 0x246bd7e8) line 175 + 12 bytes
KERNEL32! 7c80b729()

QS60Data::screenDevice() calls CCoeEnv::static(), which gets the pointer from the dll's tls (which is per thread based) which is initialized for the main thread only as far as i see...so it returns garbage for the secondary thread and the subsequent call crashes on the garbage pointer.
Creating CCoeEnv for the secondary tread in the run() panics, because of the already installed active scheduler.