Custom Query (245 matches)
Results (25 - 27 of 245)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #164 | wontfix | execv() doesn't stop the original program | ||
| Description |
Programs compiled with GCC 3.3.5 (and linked against libc061 or libc062) fail to stop the original process when execv() (or _execv()) is used. Compiling and running the attached testcase using
works fine with GCC 3.2.2 (libc 0.5.1) in that always only one process of the name exec_test is running. Compiled with GCC 3.3.5 the process list grows with every call of execv() until about 150 processes are reached at which point some memory area runs out of space here and the process crashes (and all others with it). This problem basically keeps me from producing a high-memory enabled version of Firefox and Thunderbird. |
|||
| #171 | wontfix | Use POPUPLOG.OS2 mechanism in newer libc | ||
| Description |
OS/2 programs that crash write information to <DRIVE>:\POPUPLOG.OS2 if SUPRESSPOPUPS=<DRIVE> is set in Config.sys (which on most installations of OS/2 and eCS seems to be the case). This mechanism also worked in programs linked with libc 0.5.x but not any more when linked against libc 0.6.x. This is bad because users are used to look in POPUPLOG.OS2 if a program disappears. The information logged in those crash screens is also well documented in the OS/2 debugging guide (?) and so this may give hints for developers of these programs. Even though more capable mechanisms exist for this, many users are not set up to take e.g. program dumps. And while libc 0.6.x programs still output crash information to the console, most users (or GUI programs) will not see this, so to it appears that the program just vanished for no reason. (This was already some time ago discussed on the libc list/newsgroup but never opened this as a ticket.) |
|||
| #188 | wontfix | Cannot debug long C files | ||
| Description |
I'm not actually sure if this is a problem of the compiler, the linker, or the symbol format used by the debuggers. But I cannot debug long C files because in the debugger I am shown the wrong lines. An example of such a problem is the SQLite amalgamation which has almost 68000 source lines. In the debugger I am put to line 1954 when I should really be looking at line 67487. That made me think the limit was 216 but I then cut the source down to 63000 lines by removing Win and Unix cases and still was put to line ~28800 when I should have been looking at 62205... This is with GCC 3.3.5 CSD3. |
|||
