Warning: Can't synchronize with repository "(default)" (No changeset 96d22ec3fa3ef6de3ea8dc0d7d398adc9aa071cf in the repository). Look in the Trac log for more information.

Ticket #409 (closed defect: worksforme)

Opened 4 years ago

Last modified 4 years ago

Abyss goes into an infinite loop

Reported by: dkogan Owned by: mickey
Priority: major Milestone:
Component: fso-abyss Version:
Keywords: Cc:

Description

I'm running abyss-0.3.3, and I see abyss use all my CPU under some conditions.

I set up a GPRS connection in my GTA02, and an http proxy to use that GPRS connection from my laptop over usb0. If I try to load a website (latimes.com) through that proxy, the website never finishes loading, but stalls out instead. This would happen ofter with the old muxer as well, however cycling the GPRS connection would bring it back. With the new muxer, one of several failure scenarios happen:

  1. Abyss begins to use all available CPU immediately.
  2. org.freesmartphone.GSM.PDP.DeactivateContext? fails to deactivate the ppp connection with pppd still running, but ppp0 down. Abyss starts to hog the cpu here. In this state, pppd sometimes responds to SIGTERM and sometimes not.

One of these failure cases happen every time. If pppd is running and abyss uses all the cpu, _transport_actionCallback() is called continuously, with condition=IN. If pppd is no longer running (because of a SIGKILL), Abyss still uses all the cpu, but _transport_actionCallback() is no longer called.

Change History

comment:1 Changed 4 years ago by mickey

I can not reproduce this with HEAD. Can you please retry with HEAD or the following versions for the dependencies:

libfsotransport 0.3.1 libgsm0710 1.1.1 libgsm0710mux 0.3.4

comment:2 Changed 4 years ago by dkogan

  • Status changed from new to closed
  • Resolution set to worksforme

I updated to the latest unstable SHR image (as of late May 2009) and no longer see this problem with Abyss 0.3.3. Resolving.

Note: See TracTickets for help on using tickets.