headers
kLIBC | 21 Nov 2006 00:37
Picon

[kLIBC] #130: Dynamic loading of libc

#130: Dynamic loading of libc
--------------------+-------------------------------------------------------
 Reporter:  shadow  |       Owner:  bird 
     Type:  defect  |      Status:  new  
 Priority:  normal  |   Milestone:       
Component:  libc    |     Version:  0.6.1
 Severity:  normal  |    Keywords:       
--------------------+-------------------------------------------------------
 When a library using libc is loaded dynamically, it cannot be unloaded
 again (dynamically), because libc registers exit handlers.
 
 Either we need a way to unregister those handlers, or libc should stay in
 memory, so that at least the primary library gets unloaded.
 
 Possible solution:
 libc loads itself dynamically in its InitTerm function.

-- 
Ticket URL: <http://svn.netlabs.org/libc/ticket/130>
kLIBC <http://svn.netlabs.org/libc>
kLIBC
Permalink | Reply | 1 comment |
headers
kLIBC | 21 Nov 2006 15:31
Picon

[kLIBC] #131: fork() failed, when BSS segment is too big

#131: fork() failed, when BSS segment is too big
--------------------+-------------------------------------------------------
 Reporter:  guest   |       Owner:  bird 
     Type:  defect  |      Status:  new  
 Priority:  normal  |   Milestone:       
Component:  libc    |     Version:  0.6.1
 Severity:  normal  |    Keywords:       
--------------------+-------------------------------------------------------
 The attached testcase demonstate the fault.
 
 fork() works fine with BSS_SIZE_MB value up to 62
 It fail with increasing values from 63 and return 16 instead negative
 value.

-- 
Ticket URL: <http://svn.netlabs.org/libc/ticket/131>
kLIBC <http://svn.netlabs.org/libc>
kLIBC
Permalink | Reply | 2 comments |
headers
James Moe | 22 Nov 2006 07:38
Favicon

What is this trace log?


Hello,
  A log file named <libc_01fe.log> was discovered in a program's
directory. The first 35 lines are shown.
  What is it?
  How is it triggered?

----[ start of libc_01fe.log ]----
Opened log at 2006-11-21 10:46:00.18
Process ID: 0x1fe (510) Parent PID: 0x19 (25)
Exe hmte  : 0xf2e (E:\APPS\PMMAIL\BIN\PMMAIL.EXE)
First arg : E:\APPS\PMMAIL\BIN\PMMAIL.EXE
Second arg:
CRT Module: LIBC061 hmod=0xa3d
__libc_logInit: addr 0x1db8b241 iObj=0 offObj=0x1b241
   Millsecond Timestamp.
   |     Thread ID.
   |     |  Call Nesting Level.
   |     |  |   Log Group.
   |     |  |   |    Message Type.
   |     |  |   |    |    errno in hex (0xface if not available).
   |     |  |   |    |    |      Function Name.
   |     |  |   |    |    |      |       Millisconds In function (Optional).
   v     v  v   v    v    v      v       v
xxxxxxxx tt nn gggg dddd eeee function [(ms)]: message
00c30c03 05 00 0018 Mesg 0002 spmCheck:
SPM Dump
========

uVersion               0x10003
(Continue reading)

Permalink | Reply | 2 comments |
headers
knut st. osmundsen | 22 Nov 2006 08:49
Favicon

Re: What is this trace log?

James Moe wrote:
> Hello,
>   A log file named <libc_01fe.log> was discovered in a program's
> directory. The first 35 lines are shown.
>   What is it?
>   How is it triggered?
> 

The shared memory seems to have been corrupted and libc will then 
perform a check/dump of it to the log file. Unless we've got more 
details about what's going on here, the log is probably very useful for me.

Kind Regards,
  knut
Permalink | Reply | 1 comment |
headers
James Moe | 23 Nov 2006 06:47
Favicon

Re: What is this trace log?


knut st. osmundsen wrote:
>>   A log file named <libc_01fe.log> was discovered in a program's
>> directory. The first 35 lines are shown.
>>   What is it?
>>   How is it triggered?
> 
> The shared memory seems to have been corrupted and libc will then 
> perform a check/dump of it to the log file. Unless we've got more 
> details about what's going on here, the log is probably very useful for me.
> 
  What do you need?

--
jimoe (at) sohnen-moe (dot) com
Permalink | Reply | 0 comments |
headers
Peter Weilbacher | 25 Nov 2006 21:51

High memory and DosQueryAppType()

I found out that DosQueryAppType() is another function that doesn't like
to be passed filenames that are located in high memory. For Mozilla (Bug
351246), I now work around it in a similar way Andy and Knut added for a
custom DosOpen() call. But it would be great if it got "fixed" in GCC, 
too, so that including os2safe.h works around that one, too.

I still wanted to file a bug report to request this but somehow I am not
able to find out how to get login details for Trac...
--

-- 
Greetings,  | My From: address is valid as is the version without "spam"
   Peter.   |  I try to find real messages among the spam every few days
Permalink | Reply | 3 comments |
headers
Andy Willis | 25 Nov 2006 22:12
Picon

Re: High memory and DosQueryAppType()

Peter Weilbacher wrote:
> I found out that DosQueryAppType() is another function that doesn't like
> to be passed filenames that are located in high memory. For Mozilla (Bug
> 351246), I now work around it in a similar way Andy and Knut added for a
> custom DosOpen() call. But it would be great if it got "fixed" in GCC, 
> too, so that including os2safe.h works around that one, too.
> 
> I still wanted to file a bug report to request this but somehow I am not
> able to find out how to get login details for Trac...

I told Knut about it over IRC, he said that DosPgmExec may also have 
the problem then, so we need to see how to check that... though from 
what I can tell we should be using that in the os2misc.c where the 
DosQueryAppType is used.
You need guest and netlabs to logon.
Permalink | Reply | 2 comments |
headers
kLIBC | 26 Nov 2006 12:01
Picon

[kLIBC] #132: Please add a high-mem safe wrapper for DosQueryAppType()

#132: Please add a high-mem safe wrapper for DosQueryAppType()
-------------------------+--------------------------------------------------
 Reporter:  guest        |       Owner:  bird
     Type:  enhancement  |      Status:  new 
 Priority:  normal       |   Milestone:      
Component:  libc         |     Version:      
 Severity:  normal       |    Keywords:      
-------------------------+--------------------------------------------------
 DosQueryAppType() is not listed in the high-mem supporting APIs and indeed
 it acts weird (returncode=87 and appType=0 whatever the real appType is)
 when being passed a char* as first argument that is located above 512MB.
 So it would be great, if it a SafeDosQueryAppType() wrapper could be
 written and then add it to os2safe.h.

-- 
Ticket URL: <http://svn.netlabs.org/libc/ticket/132>
kLIBC <http://svn.netlabs.org/libc>
kLIBC
Permalink | Reply | 3 comments |
headers
Peter Weilbacher | 26 Nov 2006 12:15

Re: High memory and DosQueryAppType()

On Sat, 25 Nov 2006 21:12:28 UTC, Andy Willis wrote:

> Peter Weilbacher wrote:
> > I found out that DosQueryAppType() is another function that doesn't like
> > to be passed filenames that are located in high memory. For Mozilla (Bug
> > 351246), I now work around it in a similar way Andy and Knut added for a
> > custom DosOpen() call. But it would be great if it got "fixed" in GCC, 
> > too, so that including os2safe.h works around that one, too.
> > 
> > I still wanted to file a bug report to request this but somehow I am not
> > able to find out how to get login details for Trac...
> 
> I told Knut about it over IRC, he said that DosPgmExec may also have 
> the problem then, so we need to see how to check that... though from 
> what I can tell we should be using that in the os2misc.c where the 
> DosQueryAppType is used.

In coo.prog.misc Lars Erdmann said that DosExecPgm would work with high 
memory, and he is usually right. Indeed I can find it in addendum.inf in
the section titled "APIs Supporting High Memory Objects". Hmm, although 
DosQueryNPHState is wrapped in os2safe.h and it is in that list, too.

> You need guest and netlabs to logon.

Thanks. Added Ticket #132.

Btw, at some point you did some documentation work for GCC, right? Could
you try to add a section (or a new file) about high memory to the GCC 
docs somewhere, so that more users can find out about -Zhigh-mem and 
os2safe.h and all the other stuff?
(Continue reading)

Permalink | Reply | 1 comment |
headers
kLIBC | 26 Nov 2006 16:39
Picon

Re: [kLIBC] #132: Please add a high-mem safe wrapper for DosQueryAppType()

#132: Please add a high-mem safe wrapper for DosQueryAppType()
-------------------------+--------------------------------------------------
 Reporter:  guest        |        Owner:  bird
     Type:  enhancement  |       Status:  new 
 Priority:  normal       |    Milestone:      
Component:  libc         |      Version:      
 Severity:  normal       |   Resolution:      
 Keywords:               |  
-------------------------+--------------------------------------------------
Comment (by abwillis):

 Not sure if you would rather have a separate ticket for it but as a place
 to keep track of it, WinUpper also was an unsafe call.

-- 
Ticket URL: <http://svn.netlabs.org/libc/ticket/132#comment:1>
kLIBC <http://svn.netlabs.org/libc>
kLIBC
Permalink | Reply | 0 comments |

Gmane