Closed
Bug 70928
Opened 24 years ago
Closed 24 years ago
Can't use Send Page & failing to send message after a certain size
Categories
(MailNews Core :: Composition, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9
People
(Reporter: scottputterman, Assigned: vparthas)
References
Details
(Whiteboard: [nsbeta1+])
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
Build 2001030505 Windows 2000
Whenever I go to a page and do Send Page, the status says "Sending Message" but
it never finishes. I hit Get Msg and it never appears. However, if I write a
new message and send it, it sends fine.
Reporter | ||
Comment 1•24 years ago
|
||
Apparently this doesn't happen on all pages.
It happens to me when going to a bugzilla bug report and then doing Send Page.
It happened to me when sending my status report for today (which was a file on
disk).
Eventually the server sends a timed out error report.
Here's what I found and I believe it's part of this bug. (using build
2001-03-05 on winme)
Send Page, gives me an error that Send was ok, but saving to my sent folder
failed. Sending a large attachment also gives me this error. This only happens
if I have selected my IMAP Sent folder as the designated folder to send a copy.
If I change my Copy to Sent folder to point to my Local Sent folder I don't get
this error and it both sends and copies to the designated folder.
Note: once this fails to copy to my IMAP sent folder, I can no longer send
anything without getting the error until I close the app and relaunch. When
closing the app, I get a crash. Talkback call stack:
nsMsgComposeAndSend::GetDefaultPrompt
[d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgSend.cpp, line 226]
nsMsgComposeAndSend::NotifyListenersOnStopCopy
[d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgSend.cpp, line 3379]
CopyListener::OnStopCopy
[d:\builds\seamonkey\mozilla\mailnews\compose\src\nsMsgCopy.cpp, line 142]
nsMsgCopyService::ClearRequest
[d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgCopyService.cpp, line 160]
nsMsgCopyService::~nsMsgCopyService
[d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgCopyService.cpp, line 144]
nsMsgCopyService::`scalar deleting destructor'
nsMsgCopyService::Release
[d:\builds\seamonkey\mozilla\mailnews\base\src\nsMsgCopyService.cpp]
DeleteEntry
[d:\builds\seamonkey\mozilla\xpcom\components\nsServiceManager.cpp, line 259]
PL_HashTableEnumerateEntries [../../../lib/ds/plhash.c, line 414]
nsHashtable::Reset
using the 03-05-01 builds, This doesn't happen on linux
It does happen on my Mac after the 2nd or 3rd send page
Comment 4•24 years ago
|
||
add myself to cc list. buildid on win98: 2001030509
After talking to esther just tried sending a page from browser window and also
composed a new message and attached a 51kb gif file to the message. Upon sending
I saw the stauts updated to "sending message" and did not see copy complete
which usually follows after that. Did not even see the alert that comes back
"sending message failed alert". After few minutes I had minimized my mail window
and when I went back and clicked on the mail from my windows task bar I saw the
following alert" An error occurred while sending mail. The mail server
responded dredd.mcom.com timing out connection to (xxx.xx.xx.xxx) please check
the message and try again." Clicking ok on this alert brought me back the
compose window. I got both the compose windows back one for sending a page
and another for sending an attachment. From the alert message sounds like it
was not able to establish a connection to the server at all.
I have my copy of sent message go to imap sent folder.
Reporter | ||
Comment 5•24 years ago
|
||
What sheela wrote is exactly what I'm seeing. At home I also have my Sent
folder on an Imap server.
marking nsbeta1+ and moving to mozilla0.8.1. We need to be able to send
attachments and send a page.
Comment 6•24 years ago
|
||
removing my name from the cc list. change qa contact as myself cc-ing esther.
Since send is failing
QA Contact: esther → sheelar
Comment 7•24 years ago
|
||
Varada,
Tried a few send variations on going back to build 2001022606. Basically 26th
build has some potential send problems with not able to copy or timing out the
connection to the server etc. Following are a few things that I saw
-Tested sending a page, attachment, -get error send successfull but copy failed.
-But when I checked my inbox and did get message did not see two messages that I
sent.
-But after restarting the application saw those messages in inbox.
-Sending a page or an attachment from webmail to a test account-came back with
the alert "An error occurred........". and leaves you with compose window
depending on if you say cancel or okay.
However when I want to exit the application I see netscp6 still in the task
manager. I have to do ctrl+alt+delete to get rid of it. I am thinking inspite
of ok or cancel to the alert for specific messages that fail may be one of the
messages that got failed to send or copy is keeping the connection to server at
all times. So could be that the first message that fails to copy to the sent
folder or sending message could be the reason for all the following failures?
Comment 8•24 years ago
|
||
Build on 2001022118 has the problem of copying message to the sent folder when I
attached a file more than 8kb in size. I could send and copy message upto 8 kb.
I saw the failure when sending an attachment of 10kb in file size. It took a
while for the alert window to come up. It is the alert window that I mention in
my comments 2001-03-05 15:21 and eventually get back your compose window back.
Sent folder shouldn't have anything to do with this bug. I see this on the
trunk builds Win32 and I don't have a Sent folder set up so I never access the
sent folder.
It may be good to get an SMTP protocol log here, sheela.
Comment 10•24 years ago
|
||
*** Bug 71169 has been marked as a duplicate of this bug. ***
Comment 11•24 years ago
|
||
*** Bug 71169 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 12•24 years ago
|
||
Caused by problem in sockets in the netwerk code.
Fix has been checked in .
Marking fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 13•24 years ago
|
||
windows98, buildid:2001-03-08-09
Verifying this bug is fixed on windows. I still have to verify this on mac and
linux.
Comment 14•24 years ago
|
||
Varada,
For now reopening this bug for linux and Mac. Let me know if you need a
seperate bug to be filed for mac and linux.
buildid: 2001-03-08-09 and 2001-03-12-08 on linux
This is still a problem on linux. send page is not working and sending with any
attachments is also failing sending message. On a new profile on linux a simple
text message also cannot be sent.
On Mac buildid 2001-03-08-09:Sending a 141kb size jpeg file froze the
application and had to force to quit. On friday evening, I saw an that the first
time you do send page on there is an error"There was a problem including the
file http://home.netscape.com in the message would you like to continue sending
the message without this file? cancel and okay button. When I clicked ok
resulted in sending the message and copied to the sent folder. But when you see
the message only link is displayed and the page is not being displayed inline.
But the second time onwards sending a page is not resulting in the above error.
But this error is not coming up with the same build today(03-12-2001)
On windows: I do see this is fixed and as I mentioned in my earlier comments.
However, as I continued testing on that profile I did see the copy failing
window come up on windows98 only once. Sometimes I also see that the message
gets sent and the copy fails without any error.
Also reopening bug 71202
Status: RESOLVED → REOPENED
OS: Windows 2000 → Linux
Resolution: FIXED → ---
Comment 15•24 years ago
|
||
Try sending this page from linux(buildid:2001-03-12-08)
http://personalfinance.netscape.com/finance/main.html
On same builds mentioned below I am seeing that while trying to send page on
this page is failing on both linux and mac. On linux you receive the page but
the copy fails silently the first time. The second time you try to send this
page again will result in the alert window which prompts you to send the message
but will not copy. We have tried this on Esther linux machine with an existing
and new profile and have problems copying to the imap sent folder.
Mac(buildid:2001-03-08-10)On a new profile I was able to send the above page.
However as I mentioned below sending a jpeg attachment (141kb size) freezes the
application..Which means send failing with bigger file size attachments. The
above page is about 71kb which sends and copies to the sent folder.
I have attached the jpeg file I am tyring to attach and send with both mac and
linux which fails sending.
changed the severity,
Severity: normal → critical
Assignee | ||
Comment 17•24 years ago
|
||
Adding dougt and darin to the cc list because of a possibility that this problem
could be fixed in necko.
Comment 18•24 years ago
|
||
UGH!!!! after a day of debuggin this problem, I am beginning to believe that
this bug is due to our mail server flakiness. Although I have seen the problem,
I am now having a tough time to reproduce it. I have been able to sucessfully
have a mail message with a 32k+ attachment be copied to my IMAP sent directory
after I send it on both windows and linux.
Is there an isolate imap server that I can get an account on so that I can try
to reproduce without worrying about how bad our internal mail server can be
sometimes.
more investigation needed....
Comment 19•24 years ago
|
||
okay. I am able to reproduce it again. All data is getting written to the IMAP
server. We are now deadlocking on a monitor.
Comment 20•24 years ago
|
||
dougt: there's an imap server running on status.
Comment 21•24 years ago
|
||
Here is what is happening as best as I can tell.
SMTP uploads the message. During its complete, it checks if you want to save a
copy somwhere. It does and so imap proceeds to copy the message to the Sent
directory. Imap finds that there is already a connection to that server (Inbox)
and uses it (not sure if this is correct - I thought that there was one
connection per folder?). It uploads the entire message including the
attachement. It follows up with a CRLF. I see this get written to the server
without any problem. On line 4744 of nsImapProtocol, we enter
ParseIMAPandCheckForNewMail passing a command. ParseIMAPServerResponse is
called and and asks for some data from the socket via CreateNewLineFromSocket.
Now, this CreateNewLineFromSocket function basically sits on a monitor
|m_dataAvailableMonitor| until somone notifies it. The only two ways that
obviously notify this monitor is the protocol's OnDataAvailable and shutdown.
The later we don't need to worried about (in his bug). Here is the
problem, during this entire operation of uploading the file to the Sent
directory, we do not receive any nsIStreamLisenter notfications on the protocol,
deadlocking imap.
So, questions for IMAP gurus:
1. Should we be reusing the socket that was used to connect to the Inbox? Do
we have to reinitialize the protocol when doing this?
2. After uploading an attachment, are we expecting some kind of response from
the server?
3. I understand that some work has gone into removing blocking IO from IMAP.
What is the state of that? Does it have the same problem?
Also, I see alot possible unprotected critical sections. I am not totally
versed in this implementation, but it scares me that we are twittling flag bits
directly about and outside a lock on a monitor. I am wondering why this
setting/getting of flags isn't protected.
Comment 22•24 years ago
|
||
As per varada-
-changing the summary to also reflect that message after certain size cannot be
sent. This could be a long message in the compose window or you could attach a
file.
-see bug 72106 for the copy failing to imap sent folder which is dependent on
this bug.
Summary: Can't use Send Page → Can't use Send Page & failing to send message after a certain size
Reporter | ||
Comment 23•24 years ago
|
||
I'm getting differing reports on the state of the bug. I've been told offline
that we no longer have a problem sending but just a problem copying to the Sent
folder. I'm moving this to mozilla0.9 so that we can get some IMAP help after
the mailnews perf branch lands.
Target Milestone: mozilla0.8.1 → mozilla0.9
Comment 24•24 years ago
|
||
we should be re-using a connection to copy the sent msg to the sent mail folder;
not neccesarily the inbox, but some already-in-use connection. That code has
worked for a few years now, so I doubt that's your problem.
I believe when we've finished sending data that we expect an OK from the server.
That's what we're waiting for.
The imap code counts on necko only calling it on one thread, which is why the
code doesn't need to protect certain flags.
Comment 25•24 years ago
|
||
I tried replying to a very large message - it failed in the smtp code with an
invalid socket because someone had closed the socket out from under the smtp
code. This caused necko to PR_Abort. I'm not sure what would happen on a release
build, because PR_Assert doesn't abort. I'm not sure who decided to kill the socket.
Comment 26•24 years ago
|
||
I traced through this a bit more - the necko code is closing the socket and then
polling the socket, which PR_Aborts. The smtp code is not closing the socket as
near as I can tell - it seems to be the necko code acting on its own. In
nsSocketTransport::Process, we get to the eSocketState_Done case, and it calls
CloseConnection. It doesn't look like we fell through from the
eSocketState_Error case because mCurrentState was eSocketState_Done.
At this point, I'm at a bit of a loss - I'm just not familiar with this necko
code and debugging it is very difficult. I'll try generating a log.
Comment 27•24 years ago
|
||
Here's the end of the log. Note the close connection followed by the poll. It's
unclear to my why the connection was closed.
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=1969]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2010]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=1951]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
0[a926e0]: nsSocketBOS::Write [this=b8fcd30] Poll succeeded; looping back to
PR_Write
0[a926e0]: nsSocketBOS::Write [this=b8fcd30 count=2042]
58[156a1e0]: nsSocketTransport: Entering Process() [host=nsmail-1:25
this=b8fa870], aSelectFlags=1, CurrentState=5.
58[156a1e0]: nsSocketTransport: Transport [host=nsmail-1:25 this=b8fa870] is in
WaitReadWrite state [readtype=1 writetype=200 status=80470007].
58[156a1e0]: nsSocketTransport: doReadWrite [this=b8fa870, aSelectFlags=1,
mReadRequest=b905fc0, mWriteRequest=0
58[156a1e0]: nsSocketReadRequest: [this=b905fc0] inside OnRead.
58[156a1e0]: nsSocketReadRequest: [this=b905fc0] calling listener [offset=319,
count=36]
58[156a1e0]: nsSocketIS: PR_Read(count=36) returned 36
58[156a1e0]: nsSocketReadRequest: [this=b905fc0] read 36 bytes [offset=355]
58[156a1e0]: nsSocketTransport: doReadWrite [readstatus=80470007 writestatus=0
readsuspend=0 writesuspend=0 mSelectFlags=5]
58[156a1e0]: nsSocketTransport: Leaving Process() [host=nsmail-1:25
this=b8fa870], mStatus = 80470007, CurrentState=5, mSelectFlags=5
58[156a1e0]: nsSocketTransport: Entering Process() [host=nsmail-1:25
this=b8fa870], aSelectFlags=1, CurrentState=5.
58[156a1e0]: nsSocketTransport: Transport [host=nsmail-1:25 this=b8fa870] is in
WaitReadWrite state [readtype=1 writetype=200 status=80470007].
58[156a1e0]: nsSocketTransport: doReadWrite [this=b8fa870, aSelectFlags=1,
mReadRequest=b905fc0, mWriteRequest=0
58[156a1e0]: nsSocketReadRequest: [this=b905fc0] inside OnRead.
58[156a1e0]: nsSocketReadRequest: [this=b905fc0] calling listener [offset=355,
count=8192]
58[156a1e0]: nsSocketIS: PR_Read(count=1693) returned 0
58[156a1e0]: nsSocketReadRequest: [this=b905fc0] done reading socket.
58[156a1e0]: nsSocketTransport: CompleteAsyncRead [this=b8fa870]
58[156a1e0]: nsSocketTransport: doReadWrite [readstatus=0 writestatus=0
readsuspend=0 writesuspend=0 mSelectFlags=4]
58[156a1e0]: nsSocketTransport: Transport [host=nsmail-1:25 this=b8fa870] is in
Done state.
58[156a1e0]: nsSocketTransport::CloseConnection [this=b8fa870] Calling PR_Close
58[156a1e0]: nsSocketTransport: Leaving Process() [host=nsmail-1:25
this=b8fa870], mStatus = 0, CurrentState=3, mSelectFlags=4
0[a926e0]: Assertion failure: NULL != bottom, at
../../../../../pr/src/md/windows/w32poll.c:244
Comment 28•24 years ago
|
||
OK, I've found the change that's most likely causing the problem -
// From bug 71391:
//
// If the socket is not to be reused, then make sure it
// is closed once we reach eSocketState_Done.
//
if (mReuseCount == 0)
mCloseConnectionOnceDone = PR_TRUE;
Without knowing what's going on here, is it possible that the smtp code could
call SetReuseConnection() and prevent this problem? And I guess the imap code
too if the imap code is having the same problem.
Comment 29•24 years ago
|
||
possibly, but that code was added after this problem appeared. I tried setting
the reuseConnection on the IMAP socket without any luck. Maybe we would also
have to do this on the SMTP socket?
bienvenu, how about we sit down together and debug this problem?
Comment 30•24 years ago
|
||
Doug, I won't be in the office until Thursday. I tried setting ReuseConnection
to true for smtp, and that in turn revealed the underlying problem because I got
further w/o aborting. We're sending a single line that's too long for the SMTP
server (> 16K). This causes the stmp server to send us an error response about
the too long line. After reading this response, necko closes the connection.
Here's the stack trace and the code that closes the connection. After the read
succeeds, we call CompleteAsyncRead. Later on, I think we keep polling for data
and get the pr_abort.
nsSocketTransport::CompleteAsyncRead() line 516
nsSocketTransport::doReadWrite(short 0x0001) line 978
nsSocketTransport::Process(short 0x0001) line 459 + 13 bytes
else if (mSelectFlags & PR_POLL_READ) {
//
// Read data if available
//
if (aSelectFlags & PR_POLL_READ) {
readStatus = mReadRequest->OnRead();
if (mReadRequest->IsSuspended()) {
mSelectFlags &= ~PR_POLL_READ;
readStatus = NS_BASE_STREAM_WOULD_BLOCK;
}
else if (NS_SUCCEEDED(readStatus))
/* *** we get here ***** */
CompleteAsyncRead();
else if (NS_FAILED(readStatus) && (readStatus !=
NS_BASE_STREAM_WOULD_BLOCK))
return readStatus; // this must be a socket error, so bail!
}
I'm not sure why we're sending the real long line - I assume it's the editor not
inserting any linebreaks when saving as html. So, we need to fix that problem,
but I think also we need to figure out what's going on in necko.
Comment 31•24 years ago
|
||
What are your OnDataAvailable callbacks returning??
Comment 32•24 years ago
|
||
nsMsgProtocol::OnDataAvailable() always returns NS_OK.
Comment 33•24 years ago
|
||
So, I made some changes to nsMsgProtocol::PostMessage so that it will handle
extra long lines by adding a CRLF to the line. This fixes the problem because we
don't get an error back from the server. I'll attach the patch, but it's not a
good idea to check it in, for several reasons. One is that I *think* this code
will go away when Scott checks in his async write code (which I assume will be
used for smtp). The other is that I'm not sure the patch really does the right
thing in some cases - we can add an extra CRLF if we happen to get a line longer
than 100 bytes because of the way PostMessage works. When mscott resurfaces from
the branch, he can comment.
I have *not* seen the copy to sent folder problem with IMAP - though I have seen
a PR_Abort in cases where the imap connection has timed out.
Comment 34•24 years ago
|
||
Comment 35•24 years ago
|
||
bienvenu, I can semi-reliable create the
*fail-to-copy-to-sent-folder-on-imap-server* problem.
Comment 36•24 years ago
|
||
Does the attached patch fix the two problems for anyone experiencing them?
mscott, can you comment on this patch. Does this make sense for the 0.8.1 branch?
Comment 37•24 years ago
|
||
varada,
Mark this bug as resolved and I can verify it.
I am not having sending problems sending messages with attachments or sending
page on linux machine anymore. This is working for me. I had some corrupt
image files that I was trying to attach which failed to send. I can send page
and message with attachments with no problem from buildid: 2001040306 on linux.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 38•24 years ago
|
||
Marking Fixed.
Comment 39•24 years ago
|
||
verified,
2001-04-03-10linux
2001-04-03-06win98
2001-04-03-09mac
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•