headers
Steven Levine | 1 Aug 2007 01:25
Picon
Favicon

Re: Cannot create symbol file

In <46AF9A45.2070401 <at> sohnen-moe.com>, on 07/31/07
   at 01:23 PM, James Moe <jimoe <at> sohnen-moe.com> said:

Hi,

>WSeB v4.50 fp3

OK.  That's good to know.  What the dump file captured on the same system?

>> Here's a working pmdf.
>> 
>  No joy there, either. Works for you, not for me. Hmmm, what's different
>about my system?

Hard to say.  Since, things are almost working,  I have a suspect you have
the correct versions of df_ret.exe and *.sdf installed in the directory
defined by pmdfvers.lst.  Does this appear to be the case.

What I would do is check first for some sort of capacity issue.  Delete
half the symbols and try again.  Keep doing this until you get a working
setup or you run out of symbols to delete.

FWIW, I rarely use wa commands with a path.  I find it more convenient to
copy the symbol files to the directory defined by pmdfvers.lst and let
pmdf do the work.  That said, I've never not had them work.

I would recommend moving the symobol files you don't need out of the
default directory.  Perhaps one of them is causing the problem.

If you would like me to look at this failure here, I can do this if you
(Continue reading)

Permalink | Reply | 0 comments |
headers
kLIBC | 2 Aug 2007 16:24
Picon

[kLIBC] #183: libc: iconv uses alloca regardless of size

#183: libc: iconv uses alloca regardless of size
--------------------+-------------------------------------------------------
 Reporter:  bird    |       Owner:  bird                
     Type:  defect  |      Status:  new                 
 Priority:  normal  |   Milestone:  libc-0.6.4          
Component:  libc    |     Version:  0.6                 
 Severity:  normal  |    Keywords:  iconv stack overflow
--------------------+-------------------------------------------------------
 iconv uses alloca to allocate a temporary buffer regardless of whether the
 input is 2 bytes or 2MBs. It should be changed to use malloc for buffers
 larger than a few KBs so that we don't run out of stack.

-- 
Ticket URL: <http://svn.netlabs.org/libc/ticket/183>
kLIBC <http://svn.netlabs.org/libc>
kLIBC
Permalink | Reply | 0 comments |
headers
Dave Yeo | 15 Aug 2007 06:49

bug in sys/errno.h

Hi, noticed this in sys/errno.h

#define EDOOFUS         88              /* Programming error */

#define ELAST           88              /* Must be equal largest errno
*/

ELAST has errno 92 in freebsd and 96 in netbsd
Dave
Permalink | Reply | 1 comment |
headers
Peter Weilbacher | 15 Aug 2007 09:23

IO when accessing Samba

A PmW-Tb user, who has his profile located on a Samba share, found my 
unofficial Thunderbird "PmW-Tb" to be really slow when displaying 
messages while the "official" Thunderbird is fast. The difference is 
between 2s and 30s!  He sees lots of network I/O going on between the 
machine where he runs the app and the Samba server where the profile is.
We have excluded high-memory as a cause (I made a build without). So the
remaining difference is the libc version (official uses libc051, mine 
uses libc062). Any idea what could cause this? How can we proceed to 
investigate and fix this?

Btw, Mike Kaply made a remark to me some time ago that the nightly 
builds machine that he still maintains hangs every now and then. 
Apparently this is since some nightlies use GCC 3.3.5 and after extended
uptime the system memory is exhausted and the machine has to be 
rebooted. Is GCC 3.3.5 known to leak in such a way?
--

-- 
Greetings,  | My From: address is valid as is the version without "spam"
   Peter.   |     I try to find real messages among the spam once a week
Permalink | Reply | 2 comments |
headers
Knut St. Osmundsen | 15 Aug 2007 20:28
Favicon

Re: bug in sys/errno.h

Dave Yeo wrote:
> Hi, noticed this in sys/errno.h
> 
> #define EDOOFUS         88              /* Programming error */
> 
> #define ELAST           88              /* Must be equal largest errno
> */
> 
> ELAST has errno 92 in freebsd and 96 in netbsd

Right, it should be 91 on the kLIBC case (EBADVER). I've fixed this on 
the trunk. Thanks for noticing.

Kind Regards,
  knut
Permalink | Reply | 0 comments |
headers
Knut St. Osmundsen | 15 Aug 2007 20:50
Favicon

Re: IO when accessing Samba

Peter Weilbacher wrote:
> A PmW-Tb user, who has his profile located on a Samba share, found my 
> unofficial Thunderbird "PmW-Tb" to be really slow when displaying 
> messages while the "official" Thunderbird is fast. The difference is 
> between 2s and 30s!  He sees lots of network I/O going on between the 
> machine where he runs the app and the Samba server where the profile is.
> We have excluded high-memory as a cause (I made a build without). So the
> remaining difference is the libc version (official uses libc051, mine 
> uses libc062). Any idea what could cause this? How can we proceed to 
> investigate and fix this?

There are two simple ways to inspect what's going on and takes time:
  - a network sniffer that can decode SMB requests. wireshark for
    instance.
  - use the logging libc. (This of course requires the slow operations
    to actually be logged, which is a bit of a gamble.)

Anyway, my guess is that it's related to the case resolving of paths. 
That's a know issue and there is already a ticket for optimizing it.

> Btw, Mike Kaply made a remark to me some time ago that the nightly 
> builds machine that he still maintains hangs every now and then. 
> Apparently this is since some nightlies use GCC 3.3.5 and after extended
> uptime the system memory is exhausted and the machine has to be 
> rebooted. Is GCC 3.3.5 known to leak in such a way?

User processes cannot leak shared or system memory unless they are 
triggering bugs in the OS/2 kernel or similar. I've no idea what's going 
wrong for Mike.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Weilbacher | 15 Aug 2007 23:38

Re: IO when accessing Samba

On Wed, 15 Aug 2007 18:50:31 UTC, "Knut St. Osmundsen" wrote:

> Peter Weilbacher wrote:
> > A PmW-Tb user, who has his profile located on a Samba share, found my 
> > unofficial Thunderbird "PmW-Tb" to be really slow when displaying 
> > messages while the "official" Thunderbird is fast. The difference is 
> > between 2s and 30s!  He sees lots of network I/O going on between the 
> > machine where he runs the app and the Samba server where the profile is.
> > We have excluded high-memory as a cause (I made a build without). So the
> > remaining difference is the libc version (official uses libc051, mine 
> > uses libc062). Any idea what could cause this? How can we proceed to 
> > investigate and fix this?
> 
> There are two simple ways to inspect what's going on and takes time:
>   - a network sniffer that can decode SMB requests. wireshark for
>     instance.

Yes, he has done something like that. Wasn't really enlightning.

>   - use the logging libc. (This of course requires the slow operations
>     to actually be logged, which is a bit of a gamble.)

With the .logchk version of the DLL? Is there a way to reduce the output
a bit, like only logging stuff that is about disk I/O?

> Anyway, my guess is that it's related to the case resolving of paths. 
> That's a know issue and there is already a ticket for optimizing it.

That doesn't seem likely to me. There are only few paths to resolve in a
Thunderbird mail account, perhaps a dozen to a few tens. Unless it takes
(Continue reading)

Permalink | Reply | 0 comments |
headers
kLIBC | 19 Aug 2007 16:25
Picon

[kLIBC] #184: emxomfar does not accept '-' before command parameter

#184: emxomfar does not accept '-' before command parameter
--------------------+-------------------------------------------------------
 Reporter:  ydario  |       Owner:  bird      
     Type:  defect  |      Status:  new       
 Priority:  normal  |   Milestone:  libc-0.6.4
Component:  emx     |     Version:  0.6.2     
 Severity:  normal  |    Keywords:            
--------------------+-------------------------------------------------------
 While ar accepts an optional '-' before the command char, emxomfar doesn't
 because it checks for -p and then aborts.

 Proposed patch ignores also letters for valid commands


 {{{
 Index: emxomfar.c
 ===================================================================
 --- emxomfar.c  (revision 3287)
 +++ emxomfar.c  (working copy)
  <at>  <at>  -271,6 +271,11  <at>  <at> 
              usage ();
            ++i;
            break;
 +        case 'd':      // also these option can have an optional '-',
 ignore.
 +        case 'r':
 +        case 't':
 +        case 'x':
 +          break;
          default:
(Continue reading)

Permalink | Reply | 0 comments |
headers
kLIBC | 19 Aug 2007 19:51
Picon

[kLIBC] #185: Calling setlocale() from both parent and forked child crashes child

#185: Calling setlocale() from both parent and forked child crashes child
--------------------+-------------------------------------------------------
 Reporter:  ydario  |       Owner:  bird      
     Type:  defect  |      Status:  new       
 Priority:  normal  |   Milestone:  libc-0.6.4
Component:  libc    |     Version:  0.6.2     
 Severity:  normal  |    Keywords:            
--------------------+-------------------------------------------------------
 When setlocale( LC_ALL,"") is called in main program and also in the child
 forked process, the child crashes in UCONV.DLL

 Sample testcase


 {{{

 #include <locale.h>

 int local( char* who)
 {
 printf("%s set locale\n", who);
 setlocale( LC_ALL, "");
 printf("%s set locale done\n", who);
 }

 int main( void)
 {
 int pid;
 local("parent");
 pid = fork();
(Continue reading)

Permalink | Reply | 1 comment |
headers
kLIBC | 19 Aug 2007 20:18
Picon

Re: [kLIBC] #185: libc: Calling setlocale() from both parent and forked child crashes child

#185: libc: Calling setlocale() from both parent and forked child crashes child
----------------------------------------+-----------------------------------
 Reporter:  ydario                      |        Owner:  bird      
     Type:  defect                      |       Status:  closed    
 Priority:  normal                      |    Milestone:  libc-0.6.4
Component:  libc                        |      Version:  0.6.2     
 Severity:  normal                      |   Resolution:  fixed     
 Keywords:  setlocale fork crash uconv  |  
----------------------------------------+-----------------------------------
Changes (by bird):

  * keywords:  => setlocale fork crash uconv
  * summary:  Calling setlocale() from both parent and forked child crashes
              child => libc: Calling setlocale() from both
              parent and forked child crashes child

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

Gmane