Obsolete
Status Update
Comments
en...@google.com <en...@google.com> #2
interesting is thread creates for one number or for one contact? (one contact can
have more than one phone number)
have more than one phone number)
en...@google.com <en...@google.com>
jb...@android.com <jb...@android.com> #3
Good question - since the "corrupting MMS" in this case comes from an e-mail address,
the thread is created using the sender's e-mail address. I'm looking through the
code now to understand how the SMS/MMS messages are stored in the SQLite database -
perhaps this sender's e-mail address or the sheer length of the MMS message causes an
mishandled corner case?
Let me know if I need to clarify further here...
the thread is created using the sender's e-mail address. I'm looking through the
code now to understand how the SMS/MMS messages are stored in the SQLite database -
perhaps this sender's e-mail address or the sheer length of the MMS message causes an
mishandled corner case?
Let me know if I need to clarify further here...
en...@google.com <en...@google.com> #4
Hello,
I just wanted to comment that I am having the same issue.
I only realized it was happening after I added a few new contacts or responded to
numbers that were not in my contact list before I received the
announcements@t-mobile.delivery.net... (i'm assuming this is the culprit)
As a result, any reply I make to someone that was newly added or not in my contact
list will not actually send to them (it just starts a thread that is listed as
announcements@t-mobile.delivery.net) and instead sends to the first number on my
contact list...(I have changed this to my own number...)
I don't want to hard reset bc then I will have to reinstall all of my progs...
If I don't reset, I will be annoyed with responding to all new recipients as if they
are a new number being entered into an sms, for each individual reply...
Please fix this...
Thanks
Nehemiah Richardson
I just wanted to comment that I am having the same issue.
I only realized it was happening after I added a few new contacts or responded to
numbers that were not in my contact list before I received the
announcements@t-mobile.delivery.net... (i'm assuming this is the culprit)
As a result, any reply I make to someone that was newly added or not in my contact
list will not actually send to them (it just starts a thread that is listed as
announcements@t-mobile.delivery.net) and instead sends to the first number on my
contact list...(I have changed this to my own number...)
I don't want to hard reset bc then I will have to reinstall all of my progs...
If I don't reset, I will be annoyed with responding to all new recipients as if they
are a new number being entered into an sms, for each individual reply...
Please fix this...
Thanks
Nehemiah Richardson
en...@google.com <en...@google.com>
na...@google.com <na...@google.com>
ps...@google.com <ps...@google.com>
to...@google.com <to...@google.com>
sa...@google.com <sa...@google.com> #5
This issue is really annoying.
As you can probably tell, it can get you into alot of trouble.
i.e. you texting one of your buddies a joke and your girlfriend ends up getting it
instead. Yeah. Not a happy time.
As you can probably tell, it can get you into alot of trouble.
i.e. you texting one of your buddies a joke and your girlfriend ends up getting it
instead. Yeah. Not a happy time.
Description
FileInputStream is closed rather than waiting for all of its client
FileInputStreams to be closed. For example:
FileInputStream a = new FileInputStream("a");
FileInputStream b = new FileInputStream(a.getFD());
a = null;
b.read(); // may fail because 'a' may have been closed via its finalizer
We have options:
A. Don't close a FileDescriptor until its own Finalizer runs. This has the best
chance of being correct, but it adds the GC burden of a finalizable object.
B. Manually count references. This doesn't guarantee success in practice, since
a user could hold a FileDescriptor with no associated streams.
For now, I'm marking this to low priority and we will ignore it. This looks like
more of a theoretical issue than a practical one. If anyone runs into this in
practice, I think we should implement option A.
FAIL java.io.FileDescriptor.Finalize (EXEC_FAILED)
"Test for making sure that FIS/FOS.finalize() will not disturb the FD that is
still in use."
Executing java.io.FileDescriptor.Finalize
java.io.IOException
at java.io.FileInputStream.openCheck(FileInputStream.java:366)
at java.io.FileInputStream.read(FileInputStream.java:317)