|
Home > Archive > Macromedia Flash Server > September 2005 > Other Crashes
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Asa Whillock 2005-09-22, 8:46 pm |
| BTW, if any of y'all have other crash addresses, please feel free to
send them to me. I can't guarantee being able to fix them all, but
they're an easy way for the team to find and fix bugs that are causing
you problems. It's also pretty easy for me to look them up and maybe
give some direction as to what may be causing the issue. =20
FYI any crash in js32.dll I can't lookup and tell you what's going on.
However I will say that 90% of these that I've looked into are because
of leaking objects somewhere within the server script, so take a look
for that.
Thanks
Asa
-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of Asa
Whillock
Sent: Thursday, September 22, 2005 10:00 AM
To: FlashComm Mailing List
Subject: RE: [FlashComm] App fault in Comm Svr 1.5.2.138 at 0x000d3aa6
Thanks Ryan,
I'll look forward to working on this a little more when you get the
opportunity to do so. As for some more info, this is in the creation of
a shared object. So the most likely place to look is the most
frequently created SO, and not necessarily the largest one. This may be
a memory issue and some limited resource, but without digging more it's
hard to say. I'll be here when you get a free moment.
Asa
-----Original Message-----
From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
[mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of ryanm
Sent: Thursday, September 22, 2005 1:46 AM
To: FlashComm Mailing List
Subject: Re: [FlashComm] App fault in Comm Svr 1.5.2.138 at 0x000d3aa6
> I looked up the code address you listed in your crash. It has
> to do with construction of a shared object. What would crash
> in the construction there I don't know yet, but it's sparked my
> interest. What does your application do regarding shared objects,
> if anything at all. Is it possible that you can send me and Ed a code
> snippet that's related to see if we can figure out what's going on?
>
It does everything with shared objects, it's a video chat with load=20
balancing, so there is a set of shared objects to keep track of rooms=20
(names, descriptions, MOTD, etc) globally (persistant), one to keep
track of=20
users globally (not persistant), and several for administrative purposes
(banned lists, bad word lists, etc, some persistant, some not), on the=20
master that each edge server subscribes to. Each room is it's own
instance=20
of the edge app with an SO for users local to that room, as a shorcut to
having to loop through the global list to send messages to a whole room
at=20
once (I bounce a message off the SO on the server side and the SO on the
client side has a messaging function to receive them).
The most used shared object, though, is my invite pool. Basically,
there=20
is a little 1px by 1px flash piece that sits on every page of the site,
that=20
logs into an instance of the edge server app called InvitePool, which is
a=20
remote SO to the master server's InvitePool. Basically, it gives me a=20
connection to every user that is browsing the site so that another user
can=20
pop up a private chat invite to them from any page (their client
connection=20
object is stored in the SO). Pretty much, every time they click a link
it=20
disconnects and then reconnects on the next page, and every time it
connects=20
or disconnects it removes the user data from the SO and then reinserts
it=20
when the next page loads. It's not persistant, so if no one is on there
for=20
a while the GC cleans it up, and it is created the next time someone
logs=20
into the site. I have several SOs that will do that: GC unloads them if
they=20
go unused and they are recreated next time someone needs them.
I'd send you code, but since it's a load balancing setup it would be
a=20
major undertaking to reduce it to a snippet that is less than several=20
hundred lines long and runs on one server (or I guess you could run both
the=20
edge and the master on the same box). To make matters worse, I didn't
write=20
the code initially, and I haven't rewritten it completely (yet), so
there is=20
a mixture of code I'm intimately familiar with and code that I know
sucks=20
but I haven't had time to dig into yet. Right now I'm under a deadline
and=20
need to get some more tangible problems fixed, but in the next week or
two=20
I'll see if I can't narrow down what is happening when it crashes.
ryanm=20
=3D-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=3D---------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=3D---------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Michael Weck 2005-09-22, 8:46 pm |
| Hi Asa,
Here are a couple more that have show up in my event viewer:
"Reporting queued error: faulting application FlashCom.exe, version
1.5.2.138, faulting module FlashCom.exe, version 1.5.2.138, fault
address"...
- 0x0001d264
- 0x000c0101
Please forgive me if you have these already.
Thanks,
Mike
Asa Whillock wrote:
> BTW, if any of y'all have other crash addresses, please feel free to
> send them to me. I can't guarantee being able to fix them all, but
> they're an easy way for the team to find and fix bugs that are causing
> you problems. It's also pretty easy for me to look them up and maybe
> give some direction as to what may be causing the issue.
>
> FYI any crash in js32.dll I can't lookup and tell you what's going on.
> However I will say that 90% of these that I've looked into are because
> of leaking objects somewhere within the server script, so take a look
> for that.
>
> Thanks
> Asa
>
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of Asa
> Whillock
> Sent: Thursday, September 22, 2005 10:00 AM
> To: FlashComm Mailing List
> Subject: RE: [FlashComm] App fault in Comm Svr 1.5.2.138 at 0x000d3aa6
>
> Thanks Ryan,
>
> I'll look forward to working on this a little more when you get the
> opportunity to do so. As for some more info, this is in the creation of
> a shared object. So the most likely place to look is the most
> frequently created SO, and not necessarily the largest one. This may be
> a memory issue and some limited resource, but without digging more it's
> hard to say. I'll be here when you get a free moment.
>
> Asa
>
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of ryanm
> Sent: Thursday, September 22, 2005 1:46 AM
> To: FlashComm Mailing List
> Subject: Re: [FlashComm] App fault in Comm Svr 1.5.2.138 at 0x000d3aa6
>
>
>
> It does everything with shared objects, it's a video chat with load
> balancing, so there is a set of shared objects to keep track of rooms
> (names, descriptions, MOTD, etc) globally (persistant), one to keep
> track of
> users globally (not persistant), and several for administrative purposes
>
> (banned lists, bad word lists, etc, some persistant, some not), on the
> master that each edge server subscribes to. Each room is it's own
> instance
> of the edge app with an SO for users local to that room, as a shorcut to
>
> having to loop through the global list to send messages to a whole room
> at
> once (I bounce a message off the SO on the server side and the SO on the
>
> client side has a messaging function to receive them).
>
> The most used shared object, though, is my invite pool. Basically,
> there
> is a little 1px by 1px flash piece that sits on every page of the site,
> that
> logs into an instance of the edge server app called InvitePool, which is
> a
> remote SO to the master server's InvitePool. Basically, it gives me a
> connection to every user that is browsing the site so that another user
> can
> pop up a private chat invite to them from any page (their client
> connection
> object is stored in the SO). Pretty much, every time they click a link
> it
> disconnects and then reconnects on the next page, and every time it
> connects
> or disconnects it removes the user data from the SO and then reinserts
> it
> when the next page loads. It's not persistant, so if no one is on there
> for
> a while the GC cleans it up, and it is created the next time someone
> logs
> into the site. I have several SOs that will do that: GC unloads them if
> they
> go unused and they are recreated next time someone needs them.
>
> I'd send you code, but since it's a load balancing setup it would be
> a
> major undertaking to reduce it to a snippet that is less than several
> hundred lines long and runs on one server (or I guess you could run both
> the
> edge and the master on the same box). To make matters worse, I didn't
> write
> the code initially, and I haven't rewritten it completely (yet), so
> there is
> a mixture of code I'm intimately familiar with and code that I know
> sucks
> but I haven't had time to dig into yet. Right now I'm under a deadline
> and
> need to get some more tangible problems fixed, but in the next week or
> two
> I'll see if I can't narrow down what is happening when it crashes.
>
> ryanm
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
> =---------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =---------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
> =---------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =---------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
| |
| Stefan Richter 2005-09-22, 8:46 pm |
| Is this one any good? Brought my box down a few days ago.
Event Type: Error
Event Source: Application Error
Event Category: (100)
Event ID: 1000
Date: 9/18/2005
Time: 7:20:41 PM
Description:
Faulting application FlashCom.exe, version 1.5.2.138, faulting module
FlashCom.exe, version 1.5.2.138, fault address 0x000c009b.
Data:
0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 46 6c 61 ure Fla
0018: 73 68 43 6f 6d 2e 65 78 shCom.ex
0020: 65 20 31 2e 35 2e 32 2e e 1.5.2.
0028: 31 33 38 20 69 6e 20 46 138 in F
0030: 6c 61 73 68 43 6f 6d 2e lashCom.
0038: 65 78 65 20 31 2e 35 2e exe 1.5.
0040: 32 2e 31 33 38 20 61 74 2.138 at
0048: 20 6f 66 66 73 65 74 20 offset
0050: 30 30 30 63 30 30 39 62 000c009b
Stefan
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of
> Asa Whillock
> Sent: 22 September 2005 18:23
> To: FlashComm Mailing List
> Subject: [FlashComm] Other Crashes
>
> BTW, if any of y'all have other crash addresses, please feel
> free to send them to me. I can't guarantee being able to fix
> them all, but they're an easy way for the team to find and
> fix bugs that are causing you problems. It's also pretty
> easy for me to look them up and maybe give some direction as
> to what may be causing the issue.
>
> FYI any crash in js32.dll I can't lookup and tell you what's going on.
> However I will say that 90% of these that I've looked into
> are because of leaking objects somewhere within the server
> script, so take a look for that.
>
> Thanks
> Asa
>
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of
> Asa Whillock
> Sent: Thursday, September 22, 2005 10:00 AM
> To: FlashComm Mailing List
> Subject: RE: [FlashComm] App fault in Comm Svr 1.5.2.138 at 0x000d3aa6
>
> Thanks Ryan,
>
> I'll look forward to working on this a little more when you
> get the opportunity to do so. As for some more info, this is
> in the creation of a shared object. So the most likely place
> to look is the most frequently created SO, and not
> necessarily the largest one. This may be a memory issue and
> some limited resource, but without digging more it's hard to
> say. I'll be here when you get a free moment.
>
> Asa
>
> -----Original Message-----
> From: flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> [mailto:flashcomm-bounces-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org] On Behalf Of ryanm
> Sent: Thursday, September 22, 2005 1:46 AM
> To: FlashComm Mailing List
> Subject: Re: [FlashComm] App fault in Comm Svr 1.5.2.138 at 0x000d3aa6
>
> has to do
> anything at
> snippet that's
> It does everything with shared objects, it's a video chat
> with load balancing, so there is a set of shared objects to
> keep track of rooms (names, descriptions, MOTD, etc) globally
> (persistant), one to keep track of users globally (not
> persistant), and several for administrative purposes
>
> (banned lists, bad word lists, etc, some persistant, some
> not), on the master that each edge server subscribes to. Each
> room is it's own instance of the edge app with an SO for
> users local to that room, as a shorcut to
>
> having to loop through the global list to send messages to a
> whole room at once (I bounce a message off the SO on the
> server side and the SO on the
>
> client side has a messaging function to receive them).
>
> The most used shared object, though, is my invite pool.
> Basically, there is a little 1px by 1px flash piece that sits
> on every page of the site, that logs into an instance of the
> edge server app called InvitePool, which is a remote SO to
> the master server's InvitePool. Basically, it gives me a
> connection to every user that is browsing the site so that
> another user can pop up a private chat invite to them from
> any page (their client connection object is stored in the
> SO). Pretty much, every time they click a link it disconnects
> and then reconnects on the next page, and every time it
> connects or disconnects it removes the user data from the SO
> and then reinserts it when the next page loads. It's not
> persistant, so if no one is on there for a while the GC
> cleans it up, and it is created the next time someone logs
> into the site. I have several SOs that will do that: GC
> unloads them if they go unused and they are recreated next
> time someone needs them.
>
> I'd send you code, but since it's a load balancing setup
> it would be a major undertaking to reduce it to a snippet
> that is less than several hundred lines long and runs on one
> server (or I guess you could run both the edge and the master
> on the same box). To make matters worse, I didn't write the
> code initially, and I haven't rewritten it completely (yet),
> so there is a mixture of code I'm intimately familiar with
> and code that I know sucks but I haven't had time to dig into
> yet. Right now I'm under a deadline and need to get some more
> tangible problems fixed, but in the next week or two I'll see
> if I can't narrow down what is happening when it crashes.
>
> ryanm
>
>
> =-----------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =-----------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
> =---------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =---------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
> =---------------------------------------------------------
> Supported by Fig Leaf Software - http://www.figleaf.com
> =---------------------------------------------------------
>
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
=-----------------------------------------------------------
Supported by Fig Leaf Software - http://www.figleaf.com
=-----------------------------------------------------------
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
|
|
|
|
|