![]() |
Yes, I am running THTTPd with Enforcer in WinUAE. My problem is really that the crash happens kind of randomly, at least to my uneducated eyes ;)
I will try on my Classic Amiga, there, THTTPd seems to crash "faster" and more regularly... Edit: Actually, I was mistaken (no surprise here! ;)): in WinUAE too does Enforcer report violations: when running Enforcer FILE=CON: and then thttpd, I get thousands of violations (?), such as: Code:
LONG-WRITE to 00000100 data=00000000 PC: 1025F11E Does this output mean that THTTPd is really busting the memory? I am going to run SegTracker and save Enforcer's output to a file if one of you wouldn't mind looking at it :) |
Here are parts of Enforcer's output: the first hundred "violations" are like that one:
Code:
BYTE-READ from 0E5C10BF PC: 102773DC Code:
LONG-READ from 5B03971A PC: 10A9A68A Code:
BYTE-WRITE to 5B039724 data=00 PC: 1037C0BE Code:
BYTE-WRITE to 5B039796 data=00 PC: 10A99870 Code:
Date : Saturday 07-Jan-12 14:44:23 |
Try to find which locale.library call is causing the error by adding some debug prints.
btw, do you have large enough stack? Unix ports may need huge stacks. (100k+) |
Before I go on adding debug prints, I just would like to confirm that locale.library is the implementation of the functions provided by locale.h, right?
PS. Tried increasing the stack to 200,000, both in WinUAE and on my Classic Amiga, but no luck: still the same kind of "uninitialised trap #0 vector" gurus... |
Quote:
With calloc I found that if zero bytes were requested it would return NULL whereas other implementations behave the same way as malloc does when it is asked to allocate zero bytes (eg it doesn't return NULL). This is the #define I use for the calloc issue: Code:
#if !defined(FORCEINLINE) && (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) |
Thanks Novacoder, I will check the calls to calloc in THTTPd (and use your code to replace them :cool) and get inspiration from your code to eventually reimplement realloc.
But before doing that, I will follow Toni's advice and try to locate the call(s) causing all these hits in Enforcer related to locale.library, once step at a time :). |
Quote:
|
I located at least one source of Enforcer's hits related to locale.library. PHP includes this piece of code in Zend/zend_compile.c, which is called when declaring a function in PHP:
Code:
static void build_runtime_defined_function_key(zval *result, zval *name, zend_op *opline TSRMLS_DC) Code:
static void build_runtime_defined_function_key(zval *result, zval *name, zend_op *opline TSRMLS_DC) Code:
Also, does it make sense that the following simple code snippet does not produce a hit in Enforcer? Code:
#include <stdio.h> I found out that I can replace the calls to sprintf with calls to zend_sprintf, which is defined when sprintf is "broken". This replacement yields the expected results and does not produce any hit in Enforcer :cool Code:
#if ZEND_BROKEN_SPRINTF |
I think this is GCC variadic function stack parameter size issue which is (was?) problem in m68k AROS too.
GCC always converts all variadic function parameters to LONG. Amiga m68k routines expect WORD unless it has 'l' prefix or parameter is an address. Quick test: replace %c with %lc. Does it work now? |
You are absolutely right, Toni :cool I replaced the original call:
Code:
sprintf(result->value.str.val, "%c%s%s%s", '\0', name->value.str.val, filename, lineno_buf); Code:
sprintf(result->value.str.val, "%lc%s%s%s", '\0', name->value.str.val, filename, lineno_buf); Code:
%c -> %lc Now, its seems that my version of THTTPd works fine, without anymore Enforcer's hit or crash... I will revert the stack to its original size of 40,000 instead of the current 200,000 to see if I can reproduce my original crash, count on me to keep you posted ;) Thanks a lot for your kind help! |
Quote:
|
Quote:
Quote:
Quote:
Quote:
I thought most bigger projects would use some kind of memory allocation wrapper(s) for portability reasons. |
Thanks a lot Toni!
A solution could be to wrap any call to the [sn]printf family of functions so that the wrapper could automagically add 'l' in front of each format character... I guess scanf could have the same problem? When I succeed in reproducing this behaviour, I'll try and keep you posted! BTW, my apologies for saying that IXEmul was broken, it is not :cool |
PS. Dear moderators, would it be possible to add "[Solved]" :) to the title of this thread? Thanks!
|
Quote:
|
PS. Thanks Prowler!
PPS. THTTPd "starts" crashing again. I must have missed some sprintf... I am tracking them down now... It is my mistake, I mean: the solution in this thread works! :) |
Hi all!
Sorry to bump this thread so many years later :blased but I just wanted to confirm that the problem wasn't with the realloc() function, even when I was using wrongly as pointed out ;) but rather due to conflicts between ixemul.library and some patches (like MCP) that I have now sorted out! Thanks all for your help! :) |
All times are GMT +2. The time now is 21:31. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.