e32.start_service() on Emulator -> user 42 panic

[valentinvs]

Hi PyS60 community,

I can't use e32.start_service() on the emulator.

Even the most simple invocation results in a User 42 Panic that shuts down the Python interpreter.

The most simple code that I tried is this:
simplestarter.py:

import e32
e32.start_server(u"c:\\python\\simpleserver.py")

simpleserver.py:

print "i am a simple server"

I start simplestarter.py via the "Run Script" Menu Option. Needless to say that I double checked if simpleserver.py is in the directory (as supposed to be I get a KErrNotFound error if I alter the location so simplestarter is finding the script).

At this basic point I'm not sure how to do debugging. I believe that the Python installation works all right - I can run more complicated scripts (with UI and Sockets and so on) just fine. As long as I don't invoke e32.start_server().

Can somebody point me to the obvious thing I am doing wrong please? :-)

Thanks for your time.

Valentin

PS: I'm using the PyS60 1.4.2 distribution compiled from source on Windows XP Professional SP2

[bogdan.galiceanu]

Hi Valentin and welcome to the PyS60 Discussion Board.

I've tried your two scripts both on the emulator and on my phone. I'm also using 1.4.2, on WinXP SP1, and got the USER 42 panic. On my N95 it didn't do anything, no panic, no printed message. So I guess it's a bug. If after some more testing and/or other opinions you draw the conclusion that it is a bug, you can report it here.

[gaba88]

hi valentin
i also checked in the way bogdan checked it. i also got the same error in the emulator as of yours. i think the problem can be with the SDK and its a bug i think.
feelfree to have a fedback

[valentinvs]

Hi Bogdan and Gaba,

I must say that I am a bit puzzled that this seems to be a bug - I believe the ui starting a background workhorse via e32.start_server() was a very common design pattern on S60.

Is there another way to start background process?

I reported this bug to SF Bug tracker. We'll see what comes out of it...

Thank you very much for you comments.

Bye bye,
Valentin

[bogdan.galiceanu]

The closest thing to what you want is, the way I see it, this.

[GameDude]

I did some research. 1.3.22 seems to be the first version to cause panic. 1.3.21 works just fine. Since User 42 indicates problems with memory allocation, I thought maybe this has something to do with the backported obmalloc.c from python 2.5.1, which was introduced in 1.3.22.

I took obmalloc.c from 1.3.21 and replaced the 1.4.2 version with it. After this, the panic did not occur anymore.

[gaba88]

Hi Bogdan and Gaba,

I must say that I am a bit puzzled that this seems to be a bug - I believe the ui starting a background workhorse via e32.start_server() was a very common design pattern on S60.

Is there another way to start background process?

I reported this bug to SF Bug tracker. We'll see what comes out of it...

Thank you very much for you comments.

Bye bye,
Valentin

hi valentin
plz look at the wiki you will get something there.
feel free for a feedback

[valentinvs]

hi valentin
plz look at the wiki you will get something there.
feel free for a feedback

Hi Gaba,
I am note sure what you mean by "you will get something there".

But I want to follow up on the Bug report @ https://sourceforge.net/tracker/?fun...roup_id=154155

jplauril added a discussion about the bug.

The reason for this is the use of few instances of writable static data in
the current DLC allocator code that is part of obmalloc. This prevents
running several Python processes on the emulator at the same time.

To fix this in a "nice" way we'd need to perform standard WSD removal for
dlc.cpp, but since a) this problem only affects the emulator and b) WSD
removal could reduce the performance of the allocator I think we'll opt to
simply not use the DLC allocator on the emulator.

so it appears as if gamedude is right. I guess I have to use threads for the server / ui pattern which introduces tighter (lifetime) coupling and a whole heap of other problems. What a pitty...

[gaba88]

hi valentine
i was talking about starting a background process. and you are correct that gamedude is correct in its saying.

[JOM]

guess I have to use threads for the server / ui pattern which introduces tighter (lifetime) coupling and a whole heap of other problems.

Well, jplauril did say it affects only emulator. The code should be ok in real device.

Can you develop and debug without emulator? Might be easier than redesigning whole architecture? Please also consider using some stubs, might allow you to use emulator for something?

Just an idea,

--jouni

[valentinvs]

I reconsidered and patched the emulator the way GameDude suggested. It works just fine so now I have a working toolchain again.

Thanks everybody - you seem like a great community.

Byebye,
Valentin