Trap on close while initial drive scan was still in progress

Hi

This trap cascaded. I am attaching an initial analysis of the first trap in the cascade. Perhaps 
a stop flag is required? I can provide additional analysis or upload the trap file(s) to netlabs. 
Thanks

Gregg

IBM OS/2 Dump Formatter for a retail or an hstrict SMP kernel. 
Formatter is --> Internal revision 14.103a_SMP 
Dump file is --> Internal revision 14.104a_SMP (process dump) 

Symbol (c:\os2\pdpsi\pmdf\warp45_s\os2krnlr.sym) linked 
Symbol (c:\os2\pdpsi\pmdf\warp45_s\fm3.sym) linked 
Symbol (c:\os2\pdpsi\pmdf\warp45_s\pmmail.sym) linked 
Symbol (c:\os2\pdpsi\pmdf\warp45_s\fm3res.sym) linked 
Symbol (c:\os2\pdpsi\pmdf\warp45_s\fm3dll.sym) linked 
Symbol (c:\os2\pdpsi\pmdf\warp45_s\pmspl.sym) linked 
Symbol (c:\os2\pdpsi\pmdf\warp45_s\pmviop.sym) linked 
Symbol (c:\os2\pdpsi\pmdf\warp45_s\pmctls.sym) linked 
Symbol (c:\os2\pdpsi\pmdf\warp45_s\pmmerge.sym) linked 
Symbol (c:\os2\pdpsi\pmdf\warp45_s\pmwp.sym) linked 
Symbol (c:\os2\pdpsi\pmdf\warp45_s\doscall1.sym) linked 

Current slot number: 00c6 

Random trap in GBM.dll caused by double clicking a file

Hi

This seems to be random. The filename does not provide a file type and fm2 appears to try 
to open them as binary even if they are text files. It may only occur if the bin viewer is the 
internal viewer (it is too random for me to be sure but it only started happening again after I 
hosed (don't ask (-; ) the ini in my test directory and didn't bother to reenter the bin viewer 
and editor). I am attaching the 2 recent .trp files (they both are the exact same version of 
FM2). Thanks

Gregg

---------------------------------------------------------------------
To unsubscribe, e-mail: fm2-dev-unsubscribe@...
For additional commands, e-mail: fm2-dev-help@...

Re: Trap on close while initial drive scan was still in progress

In <100.905f0100f063874e.002@...>, on 10/01/11
   at 01:03 PM, "Gregg Young" <ygk@...> said:

Hi,

>This trap cascaded. I am attaching an initial analysis of the first trap
>in the cascade. Perhaps  a stop flag is required? I can provide
>additional analysis or upload the trap file(s) to netlabs.

What we probably have is a missing NULL pointer check or an uninitialized
variable.  Fixing this may be sufficient to prevent the exception.  A stop
flag in not a bad idea because it generally will allow the exit to take
effect sooner.

You probably should try the k command the dump the thread stack.  It's
worth a try, although it may not show much.  We don't force OpenWatcom to
generate standard stack frames.

When the Analyze-Thread-≥Ring3 trap shows addresses from other processes,
use

  wr pmmail

to unload the symbols and you generally get more useful output.

If the stack trace is not confused, I would suspect that DbgMsg() has been
passed a string that overflows the internal buffer.  We change for
overflow, but can not really avoid the trap in the existing code.

We could switch the the safer C library sprintf and this would prevent the

Re: Random trap in GBM.dll caused by double clicking a file

In <100.68300300fd66874e.008@...>, on 10/01/11
   at 01:16 PM, "Gregg Young" <ygk@...> said:

Hi Gregg,

>This seems to be random. The filename does not provide a file type and
>fm2 appears to try  to open them as binary even if they are text files.
>It may only occur if the bin viewer is the  internal viewer (it is too
>random for me to be sure but it only started happening again after I 
>hosed (don't ask (-; ) the ini in my test directory and didn't bother to
>reenter the bin viewer  and editor). I am attaching the 2 recent .trp
>files (they both are the exact same version of  FM2). Thanks

The first thing I recommend is that you ask Heiko for map files so that
exceptq can generate better output.

There's obviously some kind of recursion that eventually blows the stack,
but without more details of what gbm.dll is trying to do, it's hard to say
why this occurred.

Looking at the part of the dump near where fm/2 gives up control we have

 000BE4E4  1D439453   FM3DLL    0002:000B9453  between xfsopen + 25 and
xfree - 66
 000BE508  1FBFEB09   PMMERGE   0004:000FEB09  between ValidateHwnd + 15
and ValidateWindowMapDeskObj - F
 000BE510  1FC0638C   PMMERGE   0004:0010638C  between XUpdateWindow + EC
and FindTimer - 6C
 000BE67C  1FBC5860   PMMERGE   0004:000C5860  between DefSetText + 58 and
DefSetWindowParams - 48

Re: Directories on command line ignored...

In <100.f8ee0900acb2804e.045@...>, on 09/26/11
   at 11:13 AM, "Gregg Young" <ygk@...> said:

Hi Gregg,

>I agree that the command line should override the saved state. I guess
>the issue we need to  consider is what to do if the directory on the
>command line doesn't exist. Do we create it  with or without a dialog,
>abort with or without an error message or load the saved state  with or
>without a message?

After a bit of analysis, it turns out the problem is something else. 
There is already an easy for forget command line option to suppress the
saved state restore (i.e. -).  What is failing is the initial draw of the
directory containers opened on the command line.

For example

  fm3 - d:\tmp

starts up displaying just the drive tree.  However, d:\tmp is there and
will display if the drive tree is minimized.

I'm off to hunt for a solution to this nit.

Steven

--

-- 
----------------------------------------------------------------------
"Steven Levine" <steve53@...>  eCS/Warp/DIY etc.

Re: Directories on command line ignored...

In <100.f8ee0900acb2804e.045@...>, on 09/26/11
   at 11:13 AM, "Gregg Young" <ygk@...> said:

Hi Gregg,

>I agree that the command line should override the saved state. I guess
>the issue we need to  consider is what to do if the directory on the
>command line doesn't exist. Do we create it  with or without a dialog,
>abort with or without an error message or load the saved state  with or
>without a message?

This should be resolved by changeset #1635

Steven

--

-- 
----------------------------------------------------------------------
"Steven Levine" <steve53@...>  eCS/Warp/DIY etc.
www.scoug.com www.ecomstation.com
----------------------------------------------------------------------

Re: Trap on close while initial drive scan was still in progress

In <100.905f0100f063874e.002@...>, on 10/01/11
   at 01:03 PM, "Gregg Young" <ygk@...> said:

Hi,

<isaid>
>A stop
flag in not a bad idea because it generally will allow the exit to take
effect sooner.
</isaid>

It turns out we may already have such a flag named fAmClosing which gets
set when the main window starting.

We also have the misnamed fRunning, which probably should be renamed
fAmStarting and have it's sense reversed.

Steven

--

-- 
----------------------------------------------------------------------
"Steven Levine" <steve53@...>  eCS/Warp/DIY etc.
www.scoug.com www.ecomstation.com
----------------------------------------------------------------------

Re: Random trap in GBM.dll caused by double clicking a file

>
>The first thing I recommend is that you ask Heiko for map files so that
>exceptq can generate better output.

Steven

I contacted Heiko. His response is below. I created appropriate sym file and sent him a copy 
along with mapsymw.pl. I couldn't get 1,72 to trap but it has always been random. I have 
switch to 1.73 and will consider it fixed unless it happens again. I will add a note in the 
readme and help file regarding this issue. Thanks

Gregg

Hi Gregg,

please find OpenWatcom 1.8 debug versions of GBM 1.72 and 1.73
including map and sym files attached. I hope the option symfile
created the correct symfile.

I had a look at the map file already and it seems to crash inside
of libraw. There was an issue in GBM 1.72 when loading certain Canon
CR2 RAW files (and maybe others) because of a incorrectly handled
function. Eugene Gorbunoff reported this issue some time ago.
The trap dump he sent had exactly the same address and thus
I expect the issue you see is the same.

Here is some background info:
As libraw needs much more stack than GBM binary interface allowed in
the past GBM spawns an internal thread for the libraw load functions
with the required amount of stack to workaround this limitation

Re: Random trap in GBM.dll caused by double clicking a file

Steven, Heiko

It trapped again using gbm.dll 1.73 (build level info below). I have attached the exceptq 
output. Thanks

Gregg

Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#Heiko Nitzsche:1.73#@ Generalised Bitmap Module (GBM,WAT)
Vendor:          Heiko Nitzsche
Revision:        1.73
File Version:    1.73
Description:     Generalised Bitmap Module (GBM,WAT)

On Sun, 09 Oct 2011 13:17:38 -0600 (MDT) Gregg Young wrote:

>
>>
>>The first thing I recommend is that you ask Heiko for map files so that
>>exceptq can generate better output.
>
>Steven
>
>I contacted Heiko. His response is below. I created appropriate sym file and sent him a 
copy 
>along with mapsymw.pl. I couldn't get 1,72 to trap but it has always been random. I have 
>switch to 1.73 and will consider it fixed unless it happens again. I will add a note in the 
>readme and help file regarding this issue. Thanks
>

Startup speed

Steven

I removed an UnFlesh call from StubbyScanThread. It seems to speed the load time here 
significantly.  I have committed the change. I can try only running the remote and virtual 
drives through StubbyScanThread if this doesn't help on your end. Thanks

Gregg