TYPO3 Core

I guess this is related to the extension-manager issues, but since it happens out of the extensions BE-module I reported anyway.

I just transfered the site from the ISP back to my IIS6 server, and it does time out, too (because there is no memory_limit).

the web/list module is not involving the extension manager so I think that this error is not related to the memory problems of the extmng.
Could you please probide more information about the environment the site is running on.
(webserver verison, PHP version, php as cgi?...)
does the error depend on what's the list module is listing or does it happen every time?
you screenshot shows the error in the pagetree frame. How many pages do you have in your site?

My page has only 5 pages with basic templating, nothing big yet.

The error happens everytime I click on one of the "Web" tools, where the pagetree is shown. The tool itself seems to work.

I also noticed I get logged out when I click on the user admin module.

My own server is running PHP 5.0.5 on IIS6 as isapi module, my provider is running PHP 4.4.0 on linux/apache.

Debug System Information:

CONST: PHP_OS : Linux
CONST: TYPO3_OS :
CONST: php_sapi_name: apache
OTHER: TYPO3_VERSION: 4.0
OTHER: PHP_VERSION : 4.4.0
imagecreatefromgif(): 1
imagecreatefrompng(): 1
imagecreatefromjpeg(: 1
imagegif() : 1
imagepng() : 1
imagejpeg() : 1
imagettftext() : 1
OTHER: IMAGE_TYPES : 31
OTHER: memory_limit : 35M
SERVER: SERVER_PORT : 80
SERVER: SERVER_SOFTW: Apache
SERVER: GATEWAY_INTE: CGI/1.1
SERVER: SCRIPT_NAME : /typo3/install/index.php
T3CV_GFX: image_proc: 1
T3CV_GFX: gdlib : 1
T3CV_GFX: gdlib_png : 0
T3CV_GFX: gdlib_2 : 1
T3CV_GFX: im : 1
T3CV_GFX: im_path : /usr/bin/
T3CV_GFX: im_path_lz: /usr/bin/
T3CV_GFX: im_version: im5
T3CV_GFX: im_negate_: 1
T3CV_GFX: im_imvMask: 0
T3CV_GFX: im_combine: composite

hmm, I have no idea what could cause this. Since you already raised the memory for php this is most probably not the reason.
maybe an extension is causing this behaviour.

I already uninstalled all extensions I installed, nothing changed.

I found the same issue two times in the mailing list, but with 3.x versions of Typo3, and there was no answer either.

This seems to be a database-error. I think it occurs after exporting a MySQL 4.1+ DB and importing it into MySQL 4.0.

I have no idea what happens, but that seems to be the source of this error.

I got exactly the same error on my new typo3 site.
I use a linux root server with php 4.3.4 and mysql 4.0.18 on an apache 2.0.49 server. I develloped the site on my local system under windows using mysql 5.0 and then transfered everything to the linux server.
Everything works fine so far but the error occurs suddenly after creating a new page.

Maybe Telepath is right that it has something to do with the database downgrade which I also did. What could be the reason in this case? Maybe character set problems?

I found the reason for the problem.
The sql file I exported from mysql5 did not contain the statements for the auto_increment options on the uid colums.
So after I imported that file into the new server the structur was created but auto_increment was not set. As I then created a new page the record got the uid 0 which obviosly caused the pagetree generator function to crash. I guess it stucks in an endless loop or someting until the memory limit was reached.

I removed the wrong entry in the pages table with php_myadmin and started the database compare in the install tool to put the auto_increment options back in the DB. Now everything is working.

So is there anything TYPO3 can do about this? It looks like the dump from MySQL 5 was just wrong, is this correct?

Yes the reason for the trouble was that my database dump was wrong because the auto_increment settings have been missing. I have not yet checked if it is possibel to generate a MySQL4 compatibel dump witch includes auto_increment with MySQL5.
The only thing that could be done on the Typo3 side is to check why a record with uid 0 in the pages table is able to lead the pagetree generator in the BE to a crash.
As mentioned before I reckon that an endless loop could be the reason. Maybe this can be avoided. An error message should be shown in this case.

Isn't this a duplicate of 3302? (or vice versa)

There is not much we can do about this, but I will apply the attached patch so the user will be informed about the problem...

Fixed in TYPO3 4.0.3