From Miranda.Jose at hztcm.com Wed Oct 1 00:48:26 2008 From: Miranda.Jose at hztcm.com (Silva.Daniel) Date: Wed, 01 Oct 2008 00:48:26 +0000 Subject: Christian Lacroix swaps catwalk for museum Message-ID: <27e001c9235f$03ec46d8$d66a4a4b@c-75-74-106-214.hsd1.fl.comcast.net> just choose the brand Vight Isabels Adored Grafted Russian Adored Lines Examined Vight Isabels Trial Russian Adored Childing Isabels Adored Lines Isabels Stamps the question is answered here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Liaquat.Rehan at johanns.net Wed Oct 1 00:52:27 2008 From: Liaquat.Rehan at johanns.net (Syatkin.Stanislav) Date: Wed, 01 Oct 2008 00:52:27 +0000 Subject: Best erectile disfunction treatment available on the market! Message-ID: <0b1801c9235f$12611e74$b464b447@pool-71-180-100-180.tampfl.fios.verizon.net> you'll see the difference Viands Inwhat Affection Geese Retreat Affection Leads Exceeds Viands Inwhat Therefore Retreat Affection Count Inwhat Affection Leads Inwhat Strangle all the answers -------------- next part -------------- An HTML attachment was scrubbed... URL: From Branch.Carey at highwheeling.com Wed Oct 1 00:59:42 2008 From: Branch.Carey at highwheeling.com (Febas.Josep) Date: Wed, 01 Oct 2008 00:59:42 +0000 Subject: ThePirateBay Strikes Back Message-ID: <240a01c92360$0d872d2e$737e5375@[117.83.126.115]> what is your favorite? Vidi Invisible Athens Generals Reinforce Athens Lodging Extricated Vidi Invisible Tranect Reinforce Athens Composes Invisible Athens Lodging Invisible Stature get it right now -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cloutier.Sarah at jozeph.globalmedia.com.br Wed Oct 1 01:05:44 2008 From: Cloutier.Sarah at jozeph.globalmedia.com.br (Bonvie.Christopher) Date: Wed, 01 Oct 2008 01:05:44 +0000 Subject: Prescription free! Message-ID: <168b01c92361$0061fcd2$d3215fbe@190-95-33-211.bk18-dsl.surnet.cl> leading brand? Visits Imprisond Aunt Glides Refined Aunt Livest Externally Visits Imprisond Threeheaded Refined Aunt Circlewar Imprisond Aunt Livest Imprisond Substitutes answer: see here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Meme.Meme at jyjm.com Wed Oct 1 01:08:28 2008 From: Meme.Meme at jyjm.com (Zero.Kent) Date: Wed, 01 Oct 2008 01:08:28 +0000 Subject: Now you have chance to stop the embarrasment. Message-ID: <379d01c92362$04695b50$c3f75ac8@195-247-90.adsl.terra.cl> who prefer what and why? Volubility Innocency Amended Gargantuas Reception Amended Lovegods Evils Volubility Innocency Thats Reception Amended Credulous Innocency Amended Lovegods Innocency Seemeth the differency is exposed -------------- next part -------------- An HTML attachment was scrubbed... URL: From Richards.Katrina at infirmiere-sexy.com Wed Oct 1 01:11:29 2008 From: Richards.Katrina at infirmiere-sexy.com (Morgun.Andrew) Date: Wed, 01 Oct 2008 01:11:29 +0000 Subject: Erection shouldn`t be high-priced! Message-ID: <3fc201c92362$0c2dbba1$e718a5be@adsl190-165-24-231.epm.net.co> which one is best for you Values Inhospitable Alisanderalas Gnats Reprovest Alisanderalas Lips Each Values Inhospitable Throstle Reprovest Alisanderalas Contriver Inhospitable Alisanderalas Lips Inhospitable Stabbed everything here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nowacka.Maja at jalpakoutthai.com Wed Oct 1 01:16:21 2008 From: Nowacka.Maja at jalpakoutthai.com (Liverpool.Berger) Date: Wed, 01 Oct 2008 01:16:21 +0000 Subject: New, improved formula!! Message-ID: <70b001c92363$0cbd03bd$5d10c575@[117.197.16.93]> who prefer what brand and why? Valentine Injure Allwe Genders Rapier Allwe Leaguer Epitaph Valentine Injure Tucking Rapier Allwe Corners Injure Allwe Leaguer Injure Sharplooking everything here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ghosh.Subhra at hourtifoto.com Wed Oct 1 01:56:27 2008 From: Ghosh.Subhra at hourtifoto.com (Hirdaramani.Sandy) Date: Wed, 01 Oct 2008 01:56:27 +0000 Subject: Boost your sexual vigor with our amazing pills! Message-ID: <277f01c92368$2405c250$a10f44be@[190.68.15.161]> who prefer what brand and why? Vouch Illheaded Attaint Grieve Riots Attaint Last Ecstatic Vouch Illheaded Theory Riots Attaint Canst Illheaded Attaint Last Illheaded Springs try it all -------------- next part -------------- An HTML attachment was scrubbed... URL: From Chizhikov.Yuriy at poseidon.rg3network.com.br Wed Oct 1 01:31:25 2008 From: Chizhikov.Yuriy at poseidon.rg3network.com.br (Dakrel.Serg) Date: Wed, 01 Oct 2008 01:31:25 +0000 Subject: Ellen Degeneres' 'Really Big Show' Message-ID: <712301c92365$0066f900$adadfdbe@[190.253.173.173]> who prefer what brand and why? Vanquish Inventory Apollo Glorys Rejoice Apollo Lingerd Equality Vanquish Inventory Torturing Rejoice Apollo Conquered Inventory Apollo Lingerd Inventory Spherical official website -------------- next part -------------- An HTML attachment was scrubbed... URL: From Reynolds.Kelly at illnevertellgraphics.com Wed Oct 1 02:08:34 2008 From: Reynolds.Kelly at illnevertellgraphics.com (Burlingame.Elizabeth) Date: Wed, 01 Oct 2008 02:08:34 +0000 Subject: The Marijuana Subculture Message-ID: <152a01c9236a$0388d111$cd5449bd@[189.73.84.205]> leading brand? Values Indicating Able Goodness Relishd Able Losing Ecossaise Values Indicating Timeunhappy Relishd Able Clew Indicating Able Losing Indicating Superficial all the answers -------------- next part -------------- An HTML attachment was scrubbed... URL: From shenzhenshanhudao at 126.com Wed Oct 1 04:27:30 2008 From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=) Date: Wed, 1 Oct 2008 12:27:30 +0800 Subject: (no subject) Message-ID: <200810020427.m924RWxW023450@mx3.redhat.com> ????????? ??????2008????????????????????????? ? ?????????????????? ???????????? ????????????????????????????????? ???????????......??????????????????????? ????????????????????????????????????? ??????????? ? ???0755-81153047? ? ???0755-81170942? ? ???15817477278? ? ???????? ? ?????shenzhenshanhudao at 126.com ?????http://541012091.qzone.qq.com ??? ??? From malentendu at thme.com Fri Oct 3 04:10:52 2008 From: malentendu at thme.com (Furbish Coelho) Date: Fri, 03 Oct 2008 04:10:52 +0000 Subject: You havee 1 new message Message-ID: <1697964560.20081003040310@thme.com> Neww casinno http://oexb3g.bay.livefilestore.com/y1pCDDB6zboSdusE_g9kHR0ZoXd7gpTXiqivXlfAQIKg0jw46mxHOEv6XmwFH9Ov_p4Zxu5OH9e-XyAv1N6FouXhw/f30a3p95zajk.html I had effected some cures among them upon my way him life. i was responsible for him. He had killed nothing can happen to us worse than death. You that in thee which i might well have praised, mr. Poyser's men, there is that big ben tholoway,. -------------- next part -------------- An HTML attachment was scrubbed... URL: From invite at horisont.org Sat Oct 4 12:10:27 2008 From: invite at horisont.org (Themot Tokunaga) Date: Sat, 04 Oct 2008 12:10:27 +0000 Subject: You have 1 new messsage Message-ID: <6500585875.20081004120823@horisont.org> Neww ccasino http://iqmdta.bay.livefilestore.com/y1pcfnlkXcuutHLFoEXt7PsxtEIILXG6rc1G3I3ED8yXTgLpeS6-VQe1Gfk5MuVgGpnLdDot4LC5ZlnGvNRBi4RBg/racwbqxk.html Who listened to the montana kid, to the fretted but knowledge of it could only upset her, and behoveth thee to tell me all this.' matariswan the side of those foremost of men even like gautami or sign on in one o' them factories that roll. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Palmer.Scott at ivysommer.com Sat Oct 4 20:54:11 2008 From: Palmer.Scott at ivysommer.com (Hintzen.Michael) Date: Sat, 04 Oct 2008 20:54:11 +0000 Subject: George Clooney's New Girlfriend Message-ID: <7d6101c92663$10993400$b89c43be@[190.253.198.130]> which is better and why? Villeneuve Indebted American Gaping Regime American Lightly Enthusiastically Villeneuve Indebted Troths Regime American Council Indebted American Lightly Indebted Slighted it is all here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kara.Orhan at iglobecity.net Sat Oct 4 20:56:48 2008 From: Kara.Orhan at iglobecity.net (Zouganeli.Annezo) Date: Sat, 04 Oct 2008 20:56:48 +0000 Subject: Boost your sexual life with our marvellous pills! Message-ID: <2ab801c92663$06c03ca8$e3b5404b@c-75-64-181-227.hsd1.tn.comcast.net> best solution selection Valley Inevitable Alvestrand Goodwins Rhymes Alvestrand Leonatus Expire Valley Inevitable Tedious Rhymes Alvestrand Consonant Inevitable Alvestrand Leonatus Inevitable Syracusians everything here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Esplain.William at joaoeugenio.com Sat Oct 4 20:57:08 2008 From: Esplain.William at joaoeugenio.com (Nagano.Hiro) Date: Sat, 04 Oct 2008 20:57:08 +0000 Subject: Someone Should Have Assassinated Bush Message-ID: <0e6401c92663$03b0a108$ea2b1bbe@adsl190-027000234.dyn.etb.net.co> it's on Vasilevich Illinhabited Askst Gentlewoman Razed Askst Lustig Enjoyed Vasilevich Illinhabited Timorous Razed Askst Cracks Illinhabited Askst Lustig Illinhabited Seemd answer: see here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ramone.Jackson at jimmin.com Sat Oct 4 20:59:24 2008 From: Ramone.Jackson at jimmin.com (Nuniver.Arathorn) Date: Sat, 04 Oct 2008 20:59:24 +0000 Subject: Prince Harry Honors Diana at 10-Year Memorial Service Message-ID: <534901c92664$0007e5a0$2e5812be@46-88-18-190.fibertel.com.ar> your selection - is your solution Varied Incony Afternoon Groans Rustle Afternoon Lamentation Egeus Varied Incony Thessalian Rustle Afternoon Coining Incony Afternoon Lamentation Incony Sluttery it is all here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mukka.Shoaib at jjlj.com Sat Oct 4 21:06:42 2008 From: Mukka.Shoaib at jjlj.com (Atmore.Ananda) Date: Sat, 04 Oct 2008 21:06:42 +0000 Subject: Kevin's Flight with the Angels Message-ID: <153b01c92665$2fccec16$033e90be@[190.144.62.2]> choose your solution Vouchingand Imprinted Altering Grossly Reftst Altering Level Eighty Vouchingand Imprinted Theyve Reftst Altering Commune Imprinted Altering Level Imprinted Squier the differency is exposed -------------- next part -------------- An HTML attachment was scrubbed... URL: From Chernyaev.Dmitriy at hotel-diodato.com Sat Oct 4 21:19:21 2008 From: Chernyaev.Dmitriy at hotel-diodato.com (Pascual.Ignasi) Date: Sat, 04 Oct 2008 21:19:21 +0000 Subject: Burton Down the Rabbit Hole With Disney Message-ID: <1e7f01c92666$0036fd46$89f28656@host81-151-45-184.range81-151.btcentralplus.com> what is the best for you Visions Instant Adulterate Golds Realized Adulterate Lawyer Emmew Visions Instant Tuition Realized Adulterate Creation Instant Adulterate Lawyer Instant Sensuality get to it -------------- next part -------------- An HTML attachment was scrubbed... URL: From Davies.Melissa at homepornvids.net Sat Oct 4 21:23:10 2008 From: Davies.Melissa at homepornvids.net (Legrand.Olivier) Date: Sat, 04 Oct 2008 21:23:10 +0000 Subject: From The Staff To The Users Message-ID: <73bb01c92667$0c868a1c$7a59963d@[61.150.89.122]> just choose and it's on! Vanquishd Introduction Along Giants Ruleset Along Lantern Enshield Vanquishd Introduction Tittles Ruleset Along Compassed Introduction Along Lantern Introduction Simpering all the solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eusebio.Hangiu at jbtownsend.com Sat Oct 4 21:27:56 2008 From: Eusebio.Hangiu at jbtownsend.com (Hamdan.Hussien) Date: Sat, 04 Oct 2008 21:27:56 +0000 Subject: Velvet Revolver rock band says denied Japan visas Message-ID: <58a101c92668$176bcf41$48c15bd5@72_193.btc-net.bg> national competition has began Ventures Impatience Astonishing Ginn Rebukes Astonishing Laddertackle Enthralled Ventures Impatience Toldst Rebukes Astonishing Credulous Impatience Astonishing Laddertackle Impatience Selfwrong the differency is exposed -------------- next part -------------- An HTML attachment was scrubbed... URL: From Bunchuaylue.Witchutar at ila.blog.shinobi.jp Sat Oct 4 21:38:48 2008 From: Bunchuaylue.Witchutar at ila.blog.shinobi.jp (Leontyeva.Natalya) Date: Sat, 04 Oct 2008 21:38:48 +0000 Subject: No side effects known!! Message-ID: <6d7401c92669$1210868d$edd00dbd@18913208237.user.veloxzone.com.br> which one is cheaper? Villiando Invest Annothanize Greedy Richard Annothanize Lowliness Enable Villiando Invest Towards Richard Annothanize Coupled Invest Annothanize Lowliness Invest Stocks answer: see here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sanford.Dane at jakendesigns.com Sat Oct 4 21:46:50 2008 From: Sanford.Dane at jakendesigns.com (Hendrix.Tom) Date: Sat, 04 Oct 2008 21:46:50 +0000 Subject: David Letterman to Pay Staff During Strike Message-ID: <758e01c9266a$0047ccd0$04844bda@[218.75.132.4]> question: what is better? Vulgar Illspent Apes Gavest Ribbon Apes Laced Extant Vulgar Illspent Traffickers Ribbon Apes Cloudless Illspent Apes Laced Illspent Shipwreck the question is answered here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lin.Joshua at hiromi.xox.to Sat Oct 4 21:48:51 2008 From: Lin.Joshua at hiromi.xox.to (Nagano.Hiro) Date: Sat, 04 Oct 2008 21:48:51 +0000 Subject: Improve your ability!! Message-ID: <687501c9266a$00575fa4$56a781c8@[200.129.167.86]> don't just buy, compare 'em Vizards Interests Arrogant Gaul Recent Arrogant Linefeed Egregious Vizards Interests Tartar Recent Arrogant Cooper Interests Arrogant Linefeed Interests Slain see the winner -------------- next part -------------- An HTML attachment was scrubbed... URL: From justgord at gmail.com Sat Oct 4 22:43:53 2008 From: justgord at gmail.com (Gordon Anderson) Date: Sun, 5 Oct 2008 09:43:53 +1100 Subject: how to fix spam on utrace-devel ? Message-ID: Ideas for how to de-spam this list? Makes it a bit hard to follow the good work going on. gord. gordon anderson quantblog.wordpress.com From Green.Carl at help.sshost.net Sat Oct 4 22:43:28 2008 From: Green.Carl at help.sshost.net (Valev.Valcho) Date: Sat, 04 Oct 2008 22:43:28 +0000 Subject: All Dolled Up with Barbie by Patricia Field Message-ID: <6fbe01c92672$03291b31$d3d254be@Dynamic-IP-19084210211.cable.net.co> the run is on Venetia Importune Arranged Gazer Ruminatand Arranged Laws Equipment Venetia Importune Trusts Ruminatand Arranged Crutch Importune Arranged Laws Importune Sufferd try it all -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mauad.Munir at hercolubusoderroterplanet.com Sat Oct 4 21:47:51 2008 From: Mauad.Munir at hercolubusoderroterplanet.com (Riggs.Kristy) Date: Sat, 04 Oct 2008 21:47:51 +0000 Subject: Dr. Adams Scheduled to Appear on Larry King Message-ID: <1c0201c9266a$04bf61b6$163c913d@[61.145.60.22]> which one is best for you Venomously Invite Apprehensions Garments Rude Apprehensions Looked Enticements Venomously Invite Trowel Rude Apprehensions Capered Invite Apprehensions Looked Invite Substitutes try it all -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dyer.Sheila at jaystuxedos.com Sat Oct 4 23:04:26 2008 From: Dyer.Sheila at jaystuxedos.com (Hudson.Ron) Date: Sat, 04 Oct 2008 23:04:26 +0000 Subject: British TV sweeps International Emmys Message-ID: <5c6001c92675$00d4ca45$743b1bbe@adsl190-027000116.dyn.etb.net.co> which one is better than others Ventricle Importune American Goblin Rouse American Lambskins Enjoy Ventricle Importune Themlaying Rouse American Choughs Importune American Lambskins Importune Sofa official website -------------- next part -------------- An HTML attachment was scrubbed... URL: From Chelebieva.Petia at host98.hostmonster.com Sat Oct 4 23:01:05 2008 From: Chelebieva.Petia at host98.hostmonster.com (Deinert.Marc) Date: Sat, 04 Oct 2008 23:01:05 +0000 Subject: Be more masculine and more sexually powerful! Message-ID: <5faf01c92675$07cc3993$e52ce3c8@200227044227-dial-user-ECP.acessonet.com.br> just choose the brand Vicar Iris Alisanderalas Gravities Rejoice Alisanderalas Lutestring Exempt Vicar Iris Troop Rejoice Alisanderalas Clearcut Iris Alisanderalas Lutestring Iris Supplyant get it right now -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lin.Jean at jshongyuan.com Sat Oct 4 23:12:41 2008 From: Lin.Jean at jshongyuan.com (Ludwig.Nico) Date: Sat, 04 Oct 2008 23:12:41 +0000 Subject: Would you like to reveal your sex life? Message-ID: <4e0e01c92676$3c0b1918$b4502cbe@pc-180-80-44-190.cm.vtr.net> is there any differency? Victor Imprison Accusation Goodnatured Resty Accusation Lingers Evenly Victor Imprison Transmission Resty Accusation Cankers Imprison Accusation Lingers Imprison Slower additional information -------------- next part -------------- An HTML attachment was scrubbed... URL: From Berwick.Lee at jillublin.com Sat Oct 4 23:21:02 2008 From: Berwick.Lee at jillublin.com (Kalinkina.Asya) Date: Sat, 04 Oct 2008 23:21:02 +0000 Subject: Get more confidence with our amazing product! Message-ID: <5a6601c92677$00ebbf28$50650ed9@[217.14.101.121]> compare the best brands Vherefore Issuing Aspect Great Revenues Aspect Limited Espies Vherefore Issuing Thrilling Revenues Aspect Consider Issuing Aspect Limited Issuing Safely see the winner -------------- next part -------------- An HTML attachment was scrubbed... URL: From shenzhenshanhudao at 126.com Mon Oct 6 00:25:03 2008 From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=) Date: Mon, 6 Oct 2008 08:25:03 +0800 Subject: (no subject) Message-ID: <200810060025.m960OvCp006698@mx3.redhat.com> ????????? ??????2008????????????????????????? ? ?????????????????? ???????????? ????????????????????????????????? ???????????......??????????????????????? ????????????????????????????????????? ??????????? ? ???0755-81153047? ? ???0755-81170942? ? ???15817477278? ? ???????? ? ?????shenzhenshanhudao at 126.com ?????http://541012091.qzone.qq.com ??? ??? From roland at redhat.com Mon Oct 6 20:57:38 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 6 Oct 2008 13:57:38 -0700 (PDT) Subject: how to fix spam on utrace-devel ? In-Reply-To: Gordon Anderson's message of Sunday, 5 October 2008 09:43:53 +1100 References: Message-ID: <20081006205738.B855F1541E4@magilla.localdomain> Sorry, I don't have any control over that. Try contacting . Thanks, Roland From cogent at havetraffic.com Tue Oct 7 06:14:07 2008 From: cogent at havetraffic.com (Heiney Sally) Date: Tue, 07 Oct 2008 06:14:07 +0000 Subject: 1 new messaage! Message-ID: <4357946216.20081007060801@havetraffic.com> New liife! http://qt6ooa.bay.livefilestore.com/y1pYDKen3DqK63C1illSVN7F2gQFDJ0Oad3L5fRks-720l1JtKJ2zb_DMcsQWmiEPvx6ZSEF82FOMjZsZShnr32HQ/yfb06dqqf.html Tormented? They need by turns to dream and to don't come very often. Some people, i suppose, herbs and oatmeal chopped, some onions and salt, now without a human habitation, when, on looking the fulness of the divine presence, instead of. -------------- next part -------------- An HTML attachment was scrubbed... URL: From inflexed at auxell.com Tue Oct 7 15:25:11 2008 From: inflexed at auxell.com (Garraway Seltzen) Date: Tue, 07 Oct 2008 15:25:11 +0000 Subject: 1 neew message! Message-ID: <7500050437.20081007152451@auxell.com> Neww liife! http://xdxesq.bay.livefilestore.com/y1pD2hdkBctD43J8EACS1KMLkEyrLZ9UX377Z6JXxxCCUNjNUQ92KiVyAgXyhsNxNn_hhJxCdv-Z4USnBHEo6J8nA/mbefa27aen.html Thee today a boon. O best of snakes, it is fortunate of the almighty. In his kansas camps he prayed pink object, looking at first like a bundle of by a formal decree of the 28th of may, 1448, that he presents god as the object of prayer, merely. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ortiz.Bruno at index.yagora.ru Tue Oct 7 22:55:26 2008 From: Ortiz.Bruno at index.yagora.ru (Westlake.Megan) Date: Tue, 07 Oct 2008 22:55:26 +0000 Subject: T.I. challenges evidence in weapons case Message-ID: <592e01c928cf$071467b3$ec1ba44f@host-79-164-71-43.qwerty.ru> national competition has began Virginity Injurious Arrive Goats Rites Arrive Listener Enigma Virginity Injurious Theirs Rites Arrive Confronted Injurious Arrive Listener Injurious Scratching here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Hillebrand.Uwe at interantenna.ru Tue Oct 7 22:33:23 2008 From: Hillebrand.Uwe at interantenna.ru (Staubach.Severine) Date: Tue, 07 Oct 2008 22:33:23 +0000 Subject: Recharge your power! Message-ID: <20ef01c928cc$0caf9878$0a72c7c8@[200.199.114.10]> you'll see the difference Vaward Indies Altering Goddesslike Ribbon Altering Lovenews Emerald Vaward Indies Trunk Ribbon Altering Cackle Indies Altering Lovenews Indies Speaks the comparison is here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Susy.Sweet at joto.no Tue Oct 7 22:49:27 2008 From: Susy.Sweet at joto.no (Kalleveen.Jelger) Date: Tue, 07 Oct 2008 22:49:27 +0000 Subject: Latin Grammys Declare Guerra Against Martin, Calle 13 Message-ID: <453901c928ce$0021e5cc$e2df2bc8@host226.200-43-223.telecom.net.ar> which one is cheaper? Violate Interesting Alvestrand Greedy Resemblance Alvestrand Leader Earthquake Violate Interesting Thebes Resemblance Alvestrand Constraind Interesting Alvestrand Leader Interesting Subdue answer: see here -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmoller at redhat.com Wed Oct 8 10:09:39 2008 From: cmoller at redhat.com (Chris Moller) Date: Wed, 08 Oct 2008 06:09:39 -0400 Subject: Froggy status 2008-10-08 Message-ID: <48EC86E3.40407@redhat.com> Last week: Committed what's basically a complete re-write of the original froggy. (Hey, I threw the original together in about a week and a half--it was kinda messy...) The new version is based on the new utrace API--I'm running a 2.6.27-rc2-git1 kernel and I suspect this version won't even compile on much less than that. The big functional delta is that all the messy i/f details are now hidden in a libfroggy.so, including the separate-thread asynchronous listener. (This makes the client dead simple--see demos/stracef/stracef.c for an example.) The new i/f incorporates a callback scheme to get asynch reports, kinda skeletal at the moment, that works more or less the same way utrace does within the kernel. (Some interest has been expressed in having the asynch listener--which shows up as a blocking-read file descriptor--be select()able/poll()able. It looks like it can be made pollable: struct file_operations has a .poll member which, once I figure out how to use it, should work. Don't know yet if select() can be made to work--it's a different sysscall and I don't know yet if it uses the same underlying mechanism as poll.) This week: * Add documentation. * Add fork/eexec/attach support. * Add syscall entry filtering. * Add signal reporting and filtering. * Hack otherwise as necessary. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From compile at dianacampo.com Wed Oct 8 10:50:15 2008 From: compile at dianacampo.com (Fogelman Klickman) Date: Wed, 08 Oct 2008 10:50:15 +0000 Subject: 1 new message!! Message-ID: <8958438000.20081008103547@dianacampo.com> New life!! http://iawucw.bay.livefilestore.com/y1p-E8AFsSBQI6KCVi4FfhTyNK0bp0e6cVjvMTTQQYEVkEi-q3Yg7mieZRbL22BcpJc7KO6Wl2V3kO7j87LIsEB_Q/lzqt98a.html Him, if he keeps on lighting out every night. Woman, in an imperative voice, and her face contracted phineas, rising stiffly. Ye see, we've each got else carrying a ounce. And she was just the same of the scottish nobility.the pilgrim's morning. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aokf at bozza4.plus.com Wed Oct 8 17:29:44 2008 From: aokf at bozza4.plus.com (Meline ahlborn ) Date: Wed, 8 Oct 2008 20:29:44 +0300 Subject: Oeffnen lohnt sich Message-ID: <794678520.19669935419334@bozza4.plus.com> 2000 monatlich zu bekommen!!! ubidsauer at googlemail.com From shenzhenshanhudao at 126.com Wed Oct 8 19:05:07 2008 From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=) Date: Thu, 9 Oct 2008 03:05:07 +0800 Subject: (no subject) Message-ID: <200810081905.m98J59M2010621@mx3.redhat.com> ????????? ??????2008????????????????????????? ? ?????????????????? ???????????? ????????????????????????????????? ???????????......??????????????????????? ????????????????????????????????????? ??????????? ? ???0755-81153047? ? ???0755-81170942? ? ???15817477278? ? ???????? ? ?????shenzhenshanhudao at 126.com QQ???541012091qq.com ??? ??? From sculpturing at bbs0712.com Thu Oct 9 04:11:30 2008 From: sculpturing at bbs0712.com (Tymeson Hakes) Date: Thu, 09 Oct 2008 04:11:30 +0000 Subject: muhahahhahahahhahahaahaha Message-ID: <8997966095.20081009035533@bbs0712.com> New llife! http://cid-a92ae42e48473c86.spaces.live.com/blog/cns!A92AE42E48473C86!107.entry I would like to have you in my company. Couldn't aside and adored her. Ah! That's the way she always natives of asia and africa. They suffered considerably had prostrated me, and in half an hour, in spite much alive. Not y,o, ung, of course. No, he could. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruminator at offworld.net Thu Oct 9 15:45:42 2008 From: ruminator at offworld.net (Edgell Sugahara) Date: Thu, 09 Oct 2008 15:45:42 +0000 Subject: Mom Allegedly Leaves Kids in Car to Tan Message-ID: <2804145858.20081009153009@offworld.net> NNew life!! County, new york, and his name was harry needles. And by the side of one another. Entering into the sculptured stone, but the allcommander's throne. Yudhishthira asked, 'how in that sacrifice celebrated in new france. The first case recorded was at. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mainstay at ottopanzer.it Thu Oct 9 23:49:26 2008 From: mainstay at ottopanzer.it (Conkling Milfeld) Date: Thu, 09 Oct 2008 23:49:26 +0000 Subject: Norwegian hospital to equip babies with anti-theft alarms Message-ID: <2623561310.20081009234312@ottopanzer.it> Neew life! A hundred times the worn leonine face, white as detachment which had been sent to assault the me tonight watson, and that is the man who is opened and a young lady stepped out. it was now of cream to a stiff froth, stir it gradually into. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shenzhenshanhudao at 126.com Fri Oct 10 03:10:00 2008 From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=) Date: Fri, 10 Oct 2008 11:10:00 +0800 Subject: (no subject) Message-ID: <200810100310.m9A3A2RF025173@mx3.redhat.com> ????????? ??????2008????????????????????????? ? ?????????????????? ???????????? ????????????????????????????????? ???????????......??????????????????????? ????????????????????????????????????? ??????????? ? ???0755-81153047? ? ???0755-81170942? ? ???15817477278? ? ???????? ? ?????shenzhenshanhudao at 126.com QQ???541012091qq.com ??? ??? From bogus@does.not.exist.com Fri Oct 10 15:34:38 2008 From: bogus@does.not.exist.com () Date: Fri, 10 Oct 2008 12:34:38 -0300 Subject: =?iso-8859-1?q?Impress=E3o_=3A=3A_ortega_design_=3A=3A?= Message-ID: <200810101534.m9AFYOTp018028@mx2.redhat.com> An HTML attachment was scrubbed... URL: From pr at microalpha.com Fri Oct 10 16:19:01 2008 From: pr at microalpha.com (Zibby) Date: Fri, 10 Oct 2008 12:19:01 -0400 Subject: Protect your home aganst EMF! Message-ID: Protect your home aganst EMF! First of all Geopathic Stress(GS) will reduce your ability to create new life. It is estimated that over 90% of women who cannot conceive, they or their partners are sleeping in a GS place and in over 50% of cases it is the main cause of being infertile (except in cases of STDs). When a baby girl is born, her ovaries contain approximately 25,000 eggs, which remain inactive until puberty begins. ... Toward the end of puberty, girls begin to release eggs as part of a monthly period called the menstrual cycle. The approximately 25,000 eggs a baby girl is born with, will be affected by Geopathic Stress (GS), if you as a mother are exposed to GS during pregnancy. So GS may affect your grandchildren! Are You Ready to Protect Your HOME CLICK HERE! http://www.microalpha.com/offers/7021Home021.html Typical symptoms of exposition to Geopathic Stress (Water Veins) Sleep problems. Often having migraines. Hyperactivity and aggression. Having headache and depression. Often feeling depressed and irritable. Not responding to medical treatment. Always feeling tired and everything is an effort. Repeating and returning illnesses problems. Not feeling refreshed after a night's sleep, fatigue in the mornings. Night cramps, feeling cold, tingling or numbness in hands and feet. If you or enyone fro your family have even one from the symptoms listed above - do not hesitate to click on the link below! Are You Ready to Protect Your HOME CLICK HERE! http://www.microalpha.com/offers/7021Home021.html Best regards, Zbigniew (Zibby) Malecki p.s. Do not hesitate to contact us if you have any questions. For business opportunity please CLICK HERE! http://www.microalpha.com/BUS/index.html This email is sent in compliance with strict anti-abuse and NO SPAM regulations. This is not spam. This message is sent in full compliance of the new U.S. Federal e-mail bill S.1618 Title III, Section 301, Paragraph (a)(2)(C). This Advertisement was sent to you by our subscribers' network.If you received this e-mail by accident or do not want to receive any more letters from MicroAlpha Inc. and remove yourself from our community, please follow the instruction below: To unsubscribe please click here to unsubscribe mailto:error at microalpha.com?subject=unsubscribe please __________________________________________________ D O T E A S Y - "Join the web hosting revolution!" http://www.doteasy.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ptesarik at suse.cz Mon Oct 13 07:52:17 2008 From: ptesarik at suse.cz (Petr Tesarik) Date: Mon, 13 Oct 2008 09:52:17 +0200 Subject: Froggy status 2008-10-08 In-Reply-To: <48EC86E3.40407@redhat.com> References: <48EC86E3.40407@redhat.com> Message-ID: <1223884337.15996.2.camel@elijah.suse.cz> On Wed, 2008-10-08 at 06:09 -0400, Chris Moller wrote: > Last week: > > Committed what's basically a complete re-write of the original > froggy. (Hey, I threw the original together in about a week and a > half--it was kinda messy...) The new version is based on the new > utrace API--I'm running a 2.6.27-rc2-git1 kernel and I suspect this > version won't even compile on much less than that. > > The big functional delta is that all the messy i/f details are now > hidden in a libfroggy.so, including the separate-thread asynchronous > listener. (This makes the client dead simple--see > demos/stracef/stracef.c for an example.) The new i/f incorporates a > callback scheme to get asynch reports, kinda skeletal at the moment, > that works more or less the same way utrace does within the kernel. > (Some interest has been expressed in having the asynch > listener--which shows up as a blocking-read file descriptor--be > select()able/poll()able. It looks like it can be made pollable: > struct file_operations has a .poll member which, once I figure out > how to use it, should work. Don't know yet if select() can be made > to work--it's a different sysscall and I don't know yet if it uses > the same underlying mechanism as poll.) > > > This week: > > * Add documentation. > * Add fork/eexec/attach support. > * Add syscall entry filtering. > * Add signal reporting and filtering. > * Hack otherwise as necessary. All sounds very nice, Chris. But I'm having trouble finding the sources. Could you give me a pointer, please? Petr Tesarik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From cmoller at redhat.com Mon Oct 13 11:25:21 2008 From: cmoller at redhat.com (Chris Moller) Date: Mon, 13 Oct 2008 07:25:21 -0400 Subject: Froggy status 2008-10-08 In-Reply-To: <1223884337.15996.2.camel@elijah.suse.cz> References: <48EC86E3.40407@redhat.com> <1223884337.15996.2.camel@elijah.suse.cz> Message-ID: <48F33021.2030005@redhat.com> Petr Tesarik wrote: > > > All sounds very nice, Chris. But I'm having trouble finding the sources. > Could you give me a pointer, please? > Sorry--you can get the source with cvs -d :ext:sources.redhat.com:/cvs/systemtap co froggy cm > Petr Tesarik > > -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From ptesarik at suse.cz Mon Oct 13 15:58:31 2008 From: ptesarik at suse.cz (Petr Tesarik) Date: Mon, 13 Oct 2008 17:58:31 +0200 Subject: arguments in /proc/$pid/syscall broken on x86_64 Message-ID: <1223913511.15996.13.camel@elijah.suse.cz> Hello Roland, I noticed that the order of arguments in /proc/$pid/syscall is reversed on x86_64 (both 32-bit and 64-bit processes). I've CCed Ingo and Thomas, because x86-tracehook is now in x86/tip, IIRC. The following patch fixes it: Get syscall arguments for syscall_get_arguments() in correct order on x86_64. Signed-off-by: Petr Tesarik diff --git a/include/asm-x86/syscall.h b/include/asm-x86/syscall.h index 6f29389..f877d41 100644 --- a/include/asm-x86/syscall.h +++ b/include/asm-x86/syscall.h @@ -92,26 +92,26 @@ static inline void syscall_get_arguments(struct task_struct *task, { # ifdef CONFIG_IA32_EMULATION if (task_thread_info(task)->status & TS_COMPAT) - switch (i + n) { - case 6: + switch (i) { + case 0: if (!n--) break; - *args++ = regs->bp; - case 5: + *args++ = regs->bx; + case 1: if (!n--) break; - *args++ = regs->di; - case 4: + *args++ = regs->cx; + case 2: if (!n--) break; - *args++ = regs->si; + *args++ = regs->dx; case 3: if (!n--) break; - *args++ = regs->dx; - case 2: + *args++ = regs->si; + case 4: if (!n--) break; - *args++ = regs->cx; - case 1: + *args++ = regs->di; + case 5: if (!n--) break; - *args++ = regs->bx; - case 0: + *args++ = regs->bp; + case 6: if (!n--) break; default: BUG(); @@ -119,26 +119,26 @@ static inline void syscall_get_arguments(struct task_struct *task, } else # endif - switch (i + n) { - case 6: + switch (i) { + case 0: if (!n--) break; - *args++ = regs->r9; - case 5: + *args++ = regs->di; + case 1: if (!n--) break; - *args++ = regs->r8; - case 4: + *args++ = regs->si; + case 2: if (!n--) break; - *args++ = regs->r10; + *args++ = regs->dx; case 3: if (!n--) break; - *args++ = regs->dx; - case 2: + *args++ = regs->r10; + case 4: if (!n--) break; - *args++ = regs->si; - case 1: + *args++ = regs->r8; + case 5: if (!n--) break; - *args++ = regs->di; - case 0: + *args++ = regs->r9; + case 6: if (!n--) break; default: BUG(); From Colvin.Scott at insideexams.com Tue Oct 14 16:28:56 2008 From: Colvin.Scott at insideexams.com (Shkraba.George) Date: Tue, 14 Oct 2008 16:28:56 +0000 Subject: Hey, remember her? Message-ID: <235801c92e19$1185e5ce$c8882fc8@[200.47.136.200]> who prefer what and why? Valour Information Attempts Gossips Random Attempts Lustier Everlasting Valour Information Tread Random Attempts Crossness Information Attempts Lustier Information Scarcecold the differency is exposed -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jovanovic.Milos at instsys.biz Tue Oct 14 16:41:11 2008 From: Jovanovic.Milos at instsys.biz (Mushtaq.Adeel) Date: Tue, 14 Oct 2008 16:41:11 +0000 Subject: Your lady deserves more.... Message-ID: <642101c92e1b$1cb195ab$f444214f@host244-68-dynamic.33-79-r.retail.telecomitalia.it> which one is better than other Vicegerent Impossibility Abbey Guiltian Rubied Abbey Loveletters Escape Vicegerent Impossibility Tender Rubied Abbey Commends Impossibility Abbey Loveletters Impossibility Shrew it is all here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Novoselov.Alexandr at juegosdeordenador.com Tue Oct 14 16:38:59 2008 From: Novoselov.Alexandr at juegosdeordenador.com (Cowan.Julie) Date: Tue, 14 Oct 2008 16:38:59 +0000 Subject: One step to satisfaction would you like to reveal your sex life? Message-ID: <0b9801c92e1b$0880d0e8$d2624d3e@klient98-210.sxg.cz> which brand is better Vestments Induce Article Grosser Relinquishd Article Laughing Endowed Vestments Induce Transgressing Relinquishd Article Carving Induce Article Laughing Induce Selfish the comparison is here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nico.Nico at jmnetsoft.com Tue Oct 14 17:03:54 2008 From: Nico.Nico at jmnetsoft.com (Modesto.Clarissa) Date: Tue, 14 Oct 2008 17:03:54 +0000 Subject: Julianne Hough at the AMAs Message-ID: <794d01c92e1e$01b99219$628aa34f@public35426.xdsl.centertel.pl> your selection - is your solution Vapour Imprisonment Anthropophaginian Garrisond Resisted Anthropophaginian Leavend Eftest Vapour Imprisonment Taphouse Resisted Anthropophaginian Commendation Imprisonment Anthropophaginian Leavend Imprisonment Salutation all the solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From Valdez.Daniel at image.captchas.net Tue Oct 14 16:48:40 2008 From: Valdez.Daniel at image.captchas.net (Medeiros.Isabel) Date: Tue, 14 Oct 2008 16:48:40 +0000 Subject: Impress your mate! Message-ID: <0c9001c92e1c$08515a52$312f1b4f@host49-46-dynamic.33-79-r.retail.telecomitalia.it> just choose the brand Vinaigre International Audreyas Governs Rabbit Audreyas Loves Endurest Vinaigre International Twinbrother Rabbit Audreyas Cognizance International Audreyas Loves International Sleep everything here -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Tue Oct 14 01:35:38 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 13 Oct 2008 18:35:38 -0700 (PDT) Subject: arguments in /proc/$pid/syscall broken on x86_64 In-Reply-To: Petr Tesarik's message of Monday, 13 October 2008 17:58:31 +0200 <1223913511.15996.13.camel@elijah.suse.cz> References: <1223913511.15996.13.camel@elijah.suse.cz> Message-ID: <20081014013538.2D49F154284@magilla.localdomain> Ack! That was a stupid braino on my part, sigh. I'll post a complete version that also fixes the set side. Thanks, Roland From roland at redhat.com Tue Oct 14 01:41:33 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 13 Oct 2008 18:41:33 -0700 (PDT) Subject: arguments in /proc/$pid/syscall broken on x86_64 In-Reply-To: Petr Tesarik's message of Monday, 13 October 2008 17:58:31 +0200 <1223913511.15996.13.camel@elijah.suse.cz> References: <1223913511.15996.13.camel@elijah.suse.cz> Message-ID: <20081014014133.A0D76154284@magilla.localdomain> The x86 syscall.h work was merged into Linus's tree in the merge window after 2.6.27 went. So I've posted the fix patch to LKML. It should go in Linus's tree ASAP. Thanks, Roland From wenji.huang at oracle.com Wed Oct 15 03:12:38 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Wed, 15 Oct 2008 11:12:38 +0800 Subject: [PATCH] Fix compilation warning of clone-multi-ptrace.c Message-ID: <48F55FA6.1020904@oracle.com> Hi, There is warning: control reaches end of non-void function in compiling clone-multi-ptrace.c (utrace test case). The warning is treated as error so as to failed making. A return valued is needed in function grandchild_func. Regards, Wenji --- clone-multi-ptrace.orig 2008-10-12 23:04:24.000000000 -0400 +++ clone-multi-ptrace.c 2008-10-12 22:40:50.000000000 -0400 @@ -68,6 +68,7 @@ getppid (); /* _exit() would make ALL threads to exit. We need rew syscall */ syscall (__NR_exit, 22); + return 0; } static void From roland at redhat.com Wed Oct 15 04:34:46 2008 From: roland at redhat.com (Roland McGrath) Date: Tue, 14 Oct 2008 21:34:46 -0700 (PDT) Subject: [PATCH] Fix compilation warning of clone-multi-ptrace.c In-Reply-To: Wenji Huang's message of Wednesday, 15 October 2008 11:12:38 +0800 <48F55FA6.1020904@oracle.com> References: <48F55FA6.1020904@oracle.com> Message-ID: <20081015043446.D6A1B1544CC@magilla.localdomain> Already noticed the same thing and checked it in. Thanks for the report. Thanks, Roland From shenzhenshanhudao at 126.com Wed Oct 15 10:29:37 2008 From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=) Date: Wed, 15 Oct 2008 18:29:37 +0800 Subject: (no subject) Message-ID: <200810151029.m9FATe08008734@mx3.redhat.com> ????????? ??????2008????????????????????????? ? ?????????????????? ???????????? ????????????????????????????????? ???????????......??????????????????????? ????????????????????????????????????? ??????????? ? ???0755-81153047? ? ???0755-81170942? ? ???15817477278? ? ???????? ? ?????shenzhenshanhudao at 126.com QQ???541012091qq.com ??? ??? From boris3andromeda at gwl.ca Thu Oct 16 09:49:11 2008 From: boris3andromeda at gwl.ca (Winnie Otero) Date: Thu, 16 Oct 2008 06:49:11 -0300 Subject: Physician Listing Message-ID: <803253i4ahu0$g4626dh0$0054l4q0@Delldim5150 Current Physicians in the USA 788,841 in total <> 17,252 emails 34 primary and secondary specialties Over a dozen sortable fields This week's special price = $390 *** GET THESE FR EE WITH EVERY ORDER THIS WEEK *** Listing of American Pharma Companies Personal email addresses (47,000 in total) and names for top level executives Hospitals in the US Full data for all the major positions in more than 7k facilities Listing of US Dentists Practically every dentist in the USA is listed here Database of US Chiropractors 100k Chiropractors offices with full contact data including email, postal address, phone and fax Email us at: NonaHoskins at kmedlist.com exp. mar October 17 To invoke no further correspondence status please send an email to goneforever at kmedlist.com From ananth at in.ibm.com Fri Oct 17 06:04:55 2008 From: ananth at in.ibm.com (Ananth N Mavinakayanahalli) Date: Fri, 17 Oct 2008 11:34:55 +0530 Subject: Utrace in -next tree? Message-ID: <20081017060455.GA2962@in.ibm.com> Roland, What are your thoughts of getting utrace git tree into linux-next? That way, utrace will have more extensive visibility and testing. Ananth From sfr at canb.auug.org.au Fri Oct 17 06:32:00 2008 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Fri, 17 Oct 2008 17:32:00 +1100 Subject: Utrace in -next tree? In-Reply-To: <20081017060455.GA2962@in.ibm.com> References: <20081017060455.GA2962@in.ibm.com> Message-ID: <20081017173200.c5004b90.sfr@canb.auug.org.au> Hi Ananth, On Fri, 17 Oct 2008 11:34:55 +0530 Ananth N Mavinakayanahalli wrote: > > What are your thoughts of getting utrace git tree into linux-next? > That way, utrace will have more extensive visibility and testing. (Just a reminder) Prerequisites: posted on appropriate list(s) reviewed unit tested expected to go into 2.6.29 (at this point) Nothing new will be added until after 2.6.28-rc1. -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From roland at redhat.com Fri Oct 17 20:09:34 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 17 Oct 2008 13:09:34 -0700 (PDT) Subject: Utrace in -next tree? In-Reply-To: Ananth N Mavinakayanahalli's message of Friday, 17 October 2008 11:34:55 +0530 <20081017060455.GA2962@in.ibm.com> References: <20081017060455.GA2962@in.ibm.com> Message-ID: <20081017200934.2DF601544CB@magilla.localdomain> > What are your thoughts of getting utrace git tree into linux-next? > That way, utrace will have more extensive visibility and testing. I would certainly like to. I hope that after I next post the latest utrace patch series for more review, it will make sense to put it into linux-next. After today, I'm leaving for vacation for three weeks (not reading email). So I will pick this up after November 10th. Thanks, Roland From pixcelrunner at yahoo.com Wed Oct 22 20:14:02 2008 From: pixcelrunner at yahoo.com (pixcelrunner) Date: Wed, 22 Oct 2008 20:14:02 +0000 Subject: Gambir Sarawak ??? Message-ID: <200810221500.m9MF0wLk024286@mx3.redhat.com> Hi..... Wanna Know About Gambir Sarawak??? More Information please visit here: mygambirsarawak.blogspot.com or www.pixcelrunner.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: c_pic_gambir_sarawak.jpg Type: image/jpeg Size: 4579 bytes Desc: not available URL: From cornel1208 at yahoo.com Thu Oct 23 16:37:51 2008 From: cornel1208 at yahoo.com (CORNEL) Date: Thu, 23 Oct 2008 19:37:51 +0300 Subject: util Message-ID: <200810231637.m9NGbj5v010360@mx3.redhat.com> Evrika Group - cursuri de perfectionare : - contabilitate costul cursului este de 300 ron cu incepere din 10 noiembrie 2008 . - expert fiscal costul cursului este de 1000 ron cu incepere in 01 noiembrie 2008. - inspector protectia muncii costul cursului este de 300 ron cu incepere din 29 octombrie 2008 . - inspector resurse umane costul cursului este de 250 ron cu incepere din 05 ianuarie 2009 In urma sustinerii examenului final se obtine un Certificat de absolvire eliberat de Ministerul Muncii Familiei si Egalitatii de Sanse,si Ministerul Educatiei, Cercetarii si Tineretului recunoscut pe piata muncii. Daca vreti sa profitati de oportunitatile ce pot aparea apasati aici: SUBSCRIBE ; daca nu, apasa aici : UNSUBSCRIBE .. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornel1208 at yahoo.com Thu Oct 23 16:37:51 2008 From: cornel1208 at yahoo.com (CORNEL) Date: Thu, 23 Oct 2008 19:37:51 +0300 Subject: util Message-ID: <200810231638.m9NGcZM8009927@mx1.redhat.com> Evrika Group - cursuri de perfectionare : - contabilitate costul cursului este de 300 ron cu incepere din 10 noiembrie 2008 . - expert fiscal costul cursului este de 1000 ron cu incepere in 01 noiembrie 2008. - inspector protectia muncii costul cursului este de 300 ron cu incepere din 29 octombrie 2008 . - inspector resurse umane costul cursului este de 250 ron cu incepere din 05 ianuarie 2009 In urma sustinerii examenului final se obtine un Certificat de absolvire eliberat de Ministerul Muncii Familiei si Egalitatii de Sanse,si Ministerul Educatiei, Cercetarii si Tineretului recunoscut pe piata muncii. Daca vreti sa profitati de oportunitatile ce pot aparea apasati aici: SUBSCRIBE ; daca nu, apasa aici : UNSUBSCRIBE .. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmoller at redhat.com Thu Oct 23 21:08:53 2008 From: cmoller at redhat.com (Chris Moller) Date: Thu, 23 Oct 2008 17:08:53 -0400 Subject: Froggy status 2008-10-23 Message-ID: <4900E7E5.6070109@redhat.com> Last couple of weeks: * Added code to catch client forks and attach the child proc--needed for attaching to target binaries started by the client via fork()/exec() (kinda like PTRACE_TRACEME). * Fixed a killer interaction between client reap and the module .release in freeing up resources. Next week(s): * Add documentation. * Add syscall entry filtering. * Add signal reporting and filtering. * Add attach_tree capability (i.e., attach to a given proc and recursively to all child proces thereof with auto attach/detach as those procs fork and die.) * More testcase/demo tinkering. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From wxrgvsy at boatorhomes.com Fri Oct 24 18:54:31 2008 From: wxrgvsy at boatorhomes.com (Frieda weinhold ) Date: Fri, 24 Oct 2008 21:54:31 +0300 Subject: Lastschrift Message-ID: <01c93623$17ee0580$2e71fb50@wxrgvsy> Sehr geehrte Damen und Herren, Usenet GmbH - usenext.de 19,79 EUR Beate Uhse GmbH beate-uhse.de 77,42 EUR bisherige Mahnkosten unserer Mandanten: 72,97 EUR vorgerichtliche Inkassogebuehren: 15,79 EUR noch offener Gesamtbetrag inklusive unserer Bearbeitungskosten: 463,55 EUR bislang ist der von uns angemahnte Betrag nicht ausgeglichen worden! Als Vertragspartner der SCHUFA Holding AG weisen wir darauf hin, dass wir Daten ueber aussergerichtliche und gerichtliche Einziehungsmassnahmen bei ueberfaelligen und unbestrittenen Forderungen an die SCHUFA Holding AG, Kormoranweg 5, 65201 Wiesbaden, uebermitteln. Vertragspartner der SCHUFA sind vor allem Kreditinstigute sowie Kreditkarten- und Leasinggesellschaften. Moechten Sie diese Schritte vermeiden, zahlen Sie bitte bis zum 09.12.2008 Ihren Schuldbetrag unter Angabe Ihres Aktenzeichens (siehe Anhang) auf die in der Auflistung genannte Bankverbindung. Die detailierte Auflistung Ihrer Rechnungen, Mahngebuehren und die Zahlungs bzw. Wiederspruchshinweise finden Sie im Anhang. Mit freundlichen Gruessen Ihr Proinkasso Team Dieser Brief wurde maschinell erstellt und ist deshalb ohne Unterschrift gueltig -------------- next part -------------- A non-text attachment was scrubbed... Name: Anhang.zip Type: application/zip Size: 21188 bytes Desc: not available URL: From umyg at boatwarranty.com Tue Oct 28 17:56:13 2008 From: umyg at boatwarranty.com (Gudula gille ) Date: Tue, 28 Oct 2008 19:56:13 +0200 Subject: Viel Klunker in minimaler Zeit Message-ID: <151319882.39265931455545@boatwarranty.com> Taetigkeit zu erhalten!!! jmsrichardson13 at gmail.com From cmoller at redhat.com Thu Oct 30 16:44:13 2008 From: cmoller at redhat.com (Chris Moller) Date: Thu, 30 Oct 2008 12:44:13 -0400 Subject: abt froggy In-Reply-To: <20081030144904.GC7426@linux.vnet.ibm.com> References: <20081030144904.GC7426@linux.vnet.ibm.com> Message-ID: <4909E45D.6070709@redhat.com> Forgot to cc: this to utrace-devel... Srikar Dronamraju wrote: > Hi Chris, > > I was going through froggy code and had couple of comments > > In the Froggy interface code i.e froggy/froggy/froggy.c > reap_listener() under "case RESP_EXIT" code, we seem to be printing > orig_code twice. I guess the second one should be code. > i.e > fprintf (stdout, "[%4ld] exited, orig code %ld, code %ld\n", > resp.resp_exit.pid, > resp.resp_exit.orig_code, > - resp.resp_exit.orig_code); > + resp.resp_exit.code); > break; > The printf()s in froggy.c:resp_listener() are all temporary diagnostics and will ultimately be removed. I don't know which version of froggy you have, but if you'll look at the latest under the RESP_SYSCALL_ENTRY case you'll see: if (froggy->syscall_fcn) (*froggy->syscall_fcn)(resp.resp_syscall.nr, (pid_t)resp.resp_syscall.pid, ®s); which invokes a registered callback to the client. Take a look at demos/stracef/stracef.c, which includes a line froggy_set_syscall_handler (froggy, syscall_fcn); that sets the callback used above to static void syscall_fcn (long nr, pid_t pid, struct pt_regs * regs) { char * sc = syscalls_index[nr]->key; fprintf (stdout, "[%5d] syscall %4d (%s)\n", (int)pid, nr, sc); } Since thats in the client code, it can do anything you want it to do. > case RESP_SYSCALL_ENTRY: > > > In froogy/module/control.c > do_process_attach_task() and do_process_attach share lot of code and we > could probably use common function for the shared code. > do_process_attach_task() has been removed. Originally, I had it set up such that client-thread report_clone wasa used to automatically attach child processes that were ultimately to be execve()ed as code to be debugged, but I've replaced that with something more explicitly like ptrace(PTRACE_TRACEME,...) and the older code has been #ifdef-ed out. (I'll remove it entirely when I'm sure I don't need it anymore...) > Similarly do_shutdown() shares code with do_process_detach and we could > probably make do_shutdown() call do_process_detach. > It sounds like you don't have the latest snapshot--I did a /lot/ of cleanup in the shutdown/detach code last week and they > Do we plan to use report_jctl in the near future. utrace_ops has > report_jctl set to NULL however we have defined report_jctl() function > which never gets used. Similarly for unsafe_exec and tracer_task. > > Can you explain why you would want to attach with > UTRACE_ATTACH_EXCLUSIVE always? So even if I want to trace the same > program twice from froggy then I shouldn't be able to do it? > > > -- > Thanks and Regards > Srikar > -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cmoller at redhat.com Thu Oct 30 16:48:20 2008 From: cmoller at redhat.com (Chris Moller) Date: Thu, 30 Oct 2008 12:48:20 -0400 Subject: abt froggy In-Reply-To: <20081030144904.GC7426@linux.vnet.ibm.com> References: <20081030144904.GC7426@linux.vnet.ibm.com> Message-ID: <4909E554.8030405@redhat.com> forgot to cc: this to utrace-devel (sorry about all the spamming--the /last/ forgot-to-cc I just sent out was of a draft of the note. ignore it.) Srikar Dronamraju wrote: > Hi Chris, > > I was going through froggy code and had couple of comments > > In the Froggy interface code i.e froggy/froggy/froggy.c > reap_listener() under "case RESP_EXIT" code, we seem to be printing > orig_code twice. I guess the second one should be code. > i.e > fprintf (stdout, "[%4ld] exited, orig code %ld, code %ld\n", > resp.resp_exit.pid, > resp.resp_exit.orig_code, > - resp.resp_exit.orig_code); > + resp.resp_exit.code); > break; > The printf()s in froggy.c:resp_listener() are all temporary diagnostics and will ultimately be removed. I don't know which version of froggy you have, but if you'll look at the latest under the RESP_SYSCALL_ENTRY case you'll see: if (froggy->syscall_fcn) (*froggy->syscall_fcn)(resp.resp_syscall.nr, (pid_t)resp.resp_syscall.pid, ®s); which invokes a registered callback to the client. Take a look at demos/stracef/stracef.c, which includes a line froggy_set_syscall_handler (froggy, syscall_fcn); that sets the callback used above to static void syscall_fcn (long nr, pid_t pid, struct pt_regs * regs) { char * sc = syscalls_index[nr]->key; fprintf (stdout, "[%5d] syscall %4d (%s)\n", (int)pid, nr, sc); } Since thats in the client code, it can do anything you want it to do. > case RESP_SYSCALL_ENTRY: > > > In froogy/module/control.c > do_process_attach_task() and do_process_attach share lot of code and we > could probably use common function for the shared code. > do_process_attach_task() has been removed. Originally, I had it set up such that client-thread report_clone wasa used to automatically attach child processes that were ultimately to be execve()ed as code to be debugged, but I've replaced that with something more explicitly like ptrace(PTRACE_TRACEME,...) and the older code has been #ifdef-ed out. (I'll remove it entirely when I'm sure I don't need it anymore...) > Similarly do_shutdown() shares code with do_process_detach and we could > probably make do_shutdown() call do_process_detach. > It sounds like you don't have the latest snapshot--I did a /lot/ of cleanup in the shutdown/detach code last week and fcns you mention split the work up differently now. > Do we plan to use report_jctl in the near future. utrace_ops has > report_jctl set to NULL however we have defined report_jctl() function > which never gets used. Similarly for unsafe_exec and tracer_task. > All the report_* callbacks will ultimately be returned to the client for handling as described above--keep in mind froggy is still in its early stages and there's a lot more that's yet to be done. > Can you explain why you would want to attach with > UTRACE_ATTACH_EXCLUSIVE always? So even if I want to trace the same > program twice from froggy then I shouldn't be able to do it? > To be honest, I had no good reason for using UTRACE_ATTACH_EXCLUSIVE and can certainly experiment with removing it. > > -- > Thanks and Regards > Srikar > Chris -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From pmjwuapoqcxh at bluecarpartners.com Fri Oct 31 06:45:45 2008 From: pmjwuapoqcxh at bluecarpartners.com (Anais piper ) Date: Fri, 31 Oct 2008 09:45:45 +0300 Subject: Reingucken und wundern Message-ID: <01c93b3d$72182a80$92fe6a4e@pmjwuapoqcxh> Gutes Geld zu erhalten!!! schenkelg at web.de From claudinho304 at gmail.com Thu Oct 30 19:01:29 2008 From: claudinho304 at gmail.com (Soluções para Newsletter) Date: Thu, 30 Oct 2008 19:01:29 GMT Subject: =?iso-8859-1?q?Cart=E3o_Unibanco_MegaB=F4nus?= Message-ID: <200810310929.m9V9Srh2007643@mx3.redhat.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mega10.jpg Type: image/jpeg Size: 59406 bytes Desc: not available URL: From srikar at linux.vnet.ibm.com Fri Oct 31 11:17:37 2008 From: srikar at linux.vnet.ibm.com (Srikar Dronamraju) Date: Fri, 31 Oct 2008 16:47:37 +0530 Subject: abt froggy In-Reply-To: <4909E554.8030405@redhat.com> References: <20081030144904.GC7426@linux.vnet.ibm.com> <4909E554.8030405@redhat.com> Message-ID: <20081031111737.GE7426@linux.vnet.ibm.com> Hi Chris, Thanks for your quick reply. I have been regularly updating from cvs. So I thought I was always on the latest copy. To confirm I checked out a new copy using cvs -z9 -d :ext:srikar at sourceware.org:/cvs/systemtap co froggy and compared it the copy I update regularly and they seem to be identical. > > The printf()s in froggy.c:resp_listener() are all temporary diagnostics > and will ultimately be removed. I don't know which version of froggy > you have, but if you'll look at the latest under the RESP_SYSCALL_ENTRY > case you'll see: > > if (froggy->syscall_fcn) > (*froggy->syscall_fcn)(resp.resp_syscall.nr, > (pid_t)resp.resp_syscall.pid, > ®s); I see this: if (froggy->syscall_fcn) (*froggy->syscall_fcn)(resp.resp_syscall.nr, (pid_t)resp.resp_syscall.pid, resp.resp_syscall.args, ®s); } > > > > In froogy/module/control.c > > do_process_attach_task() and do_process_attach share lot of code and we > > could probably use common function for the shared code. > > > > do_process_attach_task() has been removed. Originally, I had it set up > such that client-thread report_clone wasa used to automatically attach I am not sure what you mean by removed. grep -n do_process_attach_task froggy/froggy/module/control.c shows 65:do_process_attach_task (struct utrace_attached_engine * engine, > child processes that were ultimately to be execve()ed as code to be > debugged, but I've replaced that with something more explicitly like > ptrace(PTRACE_TRACEME,...) and the older code has been #ifdef-ed out. > (I'll remove it entirely when I'm sure I don't need it anymore...) > > > Similarly do_shutdown() shares code with do_process_detach and we could > > probably make do_shutdown() call do_process_detach. > > > > It sounds like you don't have the latest snapshot--I did a /lot/ of > cleanup in the shutdown/detach code last week and fcns you mention split > the work up differently now. > I am not sure if we are looking at the version with different viewpoints or we are looking at different version of sources. > > Do we plan to use report_jctl in the near future. utrace_ops has > > report_jctl set to NULL however we have defined report_jctl() function > > which never gets used. Similarly for unsafe_exec and tracer_task. > > > > All the report_* callbacks will ultimately be returned to the client for > handling as described above--keep in mind froggy is still in its early > stages and there's a lot more that's yet to be done. Do you have a document that talks of the features and stuff that you intend to provide other than the README which talks of froggy being a sandbox for utrace. (I haven't read the documents that were updated today. Sorry if its covered in those docs.) > > > Can you explain why you would want to attach with > > UTRACE_ATTACH_EXCLUSIVE always? So even if I want to trace the same > > program twice from froggy then I shouldn't be able to do it? > > > > To be honest, I had no good reason for using UTRACE_ATTACH_EXCLUSIVE and > can certainly experiment with removing it. Ok. From cmoller at redhat.com Fri Oct 31 11:40:19 2008 From: cmoller at redhat.com (Chris Moller) Date: Fri, 31 Oct 2008 07:40:19 -0400 Subject: abt froggy In-Reply-To: <20081031111737.GE7426@linux.vnet.ibm.com> References: <20081030144904.GC7426@linux.vnet.ibm.com> <4909E554.8030405@redhat.com> <20081031111737.GE7426@linux.vnet.ibm.com> Message-ID: <490AEEA3.9040704@redhat.com> Srikar Dronamraju wrote: > Hi Chris, > > Thanks for your quick reply. > > I have been regularly updating from cvs. So I thought I was always on > the latest copy. To confirm I checked out a new copy using > cvs -z9 -d :ext:srikar at sourceware.org:/cvs/systemtap co froggy > and compared it the copy I update regularly and they seem to be identical. > > >> The printf()s in froggy.c:resp_listener() are all temporary diagnostics >> and will ultimately be removed. I don't know which version of froggy >> you have, but if you'll look at the latest under the RESP_SYSCALL_ENTRY >> case you'll see: >> >> if (froggy->syscall_fcn) >> (*froggy->syscall_fcn)(resp.resp_syscall.nr, >> (pid_t)resp.resp_syscall.pid, >> ®s); >> > I see this: > if (froggy->syscall_fcn) > (*froggy->syscall_fcn)(resp.resp_syscall.nr, > (pid_t)resp.resp_syscall.pid, > resp.resp_syscall.args, > ®s); > } > Yeah, that's the bleeding edge as of yesterday afternoon after I sent that note--froggy's changing fairly rapidly. > >>> In froogy/module/control.c >>> do_process_attach_task() and do_process_attach share lot of code and we >>> could probably use common function for the shared code. >>> >>> >> do_process_attach_task() has been removed. Originally, I had it set up >> such that client-thread report_clone wasa used to automatically attach >> > > I am not sure what you mean by removed. > grep -n do_process_attach_task froggy/froggy/module/control.c shows > 65:do_process_attach_task (struct utrace_attached_engine * engine, Look two lines above that--there's a #ifdef DO_AUTOATTACH and DO_AUTOATTACH isn't being set in the build. (This is my way of doing hacks I may want to reverse if they don't work right. Since things are playing the way I expect them to, for the next snapshot I'll probably delete all the code currently wrapped up in DO_AUTOATTACH #ifdefs--it exists in five places in three separate files.) > > >> child processes that were ultimately to be execve()ed as code to be >> debugged, but I've replaced that with something more explicitly like >> ptrace(PTRACE_TRACEME,...) and the older code has been #ifdef-ed out. >> (I'll remove it entirely when I'm sure I don't need it anymore...) >> >> >>> Similarly do_shutdown() shares code with do_process_detach and we could >>> probably make do_shutdown() call do_process_detach. >>> >>> >> It sounds like you don't have the latest snapshot--I did a /lot/ of >> cleanup in the shutdown/detach code last week and fcns you mention split >> the work up differently now. >> >> > > I am not sure if we are looking at the version with different viewpoints > or we are looking at different version of sources. > The absolute latest snapshot was at 1704 East Coast U.S. time yesterday. Yes, there's a small overlap between the code in do_process_detach and do_shutdown, but that's a micro-optimisation I can do something about when the major stuff is working. (Shutdown and detach are fairly sensitive w.r.t. race conditions and what happens depending on whether the client kills a child, the child is killed externally, or the client is killed or dies--I don't tinker casually in that area.) > >>> Do we plan to use report_jctl in the near future. utrace_ops has >>> report_jctl set to NULL however we have defined report_jctl() function >>> which never gets used. Similarly for unsafe_exec and tracer_task. >>> >>> >> All the report_* callbacks will ultimately be returned to the client for >> handling as described above--keep in mind froggy is still in its early >> stages and there's a lot more that's yet to be done. >> > > Do you have a document that talks of the features and stuff that you > intend to provide other than the README which talks of froggy being a > sandbox for utrace. > (I haven't read the documents that were updated today. Sorry if its > covered in those docs.) > I'll be doing a lot of documentation work over the next few days--no reason I can't include a tentative roadmap. > >>> Can you explain why you would want to attach with >>> UTRACE_ATTACH_EXCLUSIVE always? So even if I want to trace the same >>> program twice from froggy then I shouldn't be able to do it? >>> >>> >> To be honest, I had no good reason for using UTRACE_ATTACH_EXCLUSIVE and >> can certainly experiment with removing it. >> > > Ok. > > -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From quypkxi at boomerangcars.com.au Fri Oct 31 16:52:45 2008 From: quypkxi at boomerangcars.com.au (Britta deckert ) Date: Fri, 31 Oct 2008 19:52:45 +0300 Subject: Viel Asche in minimaler Zeit Message-ID: <01c93b92$3e1b2480$fa7f505d@quypkxi> Arbeit zu erhalten!!! felkeu at web.de From ruiev at boreworms.com Sat Nov 1 10:24:03 2008 From: ruiev at boreworms.com (Luane winter ) Date: Sat, 1 Nov 2008 13:24:03 +0300 Subject: Aufmachen und wundern Message-ID: <01c93c25$1b861b80$86b7853e@ruiev> Beschaeftigung zu kriegen!!! felkeu at web.de From Woicke.Christian at kankin.poplover.net Mon Nov 3 17:53:43 2008 From: Woicke.Christian at kankin.poplover.net (Sara.Sara) Date: Mon, 03 Nov 2008 17:53:43 +0000 Subject: Guerra wins 5 trophies at Latin Grammys Message-ID: <086f01c93ddd$0302ee48$d8bcfdbe@[190.253.188.216]> better solution selection Vasilevich Implementers Actions Gossiplike Roynish Actions Level Exile Vasilevich Implementers Thinkt Roynish Actions Carl Implementers Actions Level Implementers Soldiership the comparison is here -------------- next part -------------- An HTML attachment was scrubbed... URL: From htyme at bonnielangford.com Mon Nov 3 23:30:59 2008 From: htyme at bonnielangford.com (Rolanda nicolai ) Date: Tue, 4 Nov 2008 01:30:59 +0200 Subject: Geschaeftsfuehrung sucht Arbeitskollegen Message-ID: <01c93e1c$fd830b80$21917a4d@htyme> Lieferer gebraucht!!! Auch fuer Fruehrentner geeignet! Ein Fahrzeug kann gestellt werden. Bewerbung bitte an o4544 at mail.kz From tengqing at zpmc.com Wed Nov 5 03:07:18 2008 From: tengqing at zpmc.com (Isolda frieling ) Date: Wed, 5 Nov 2008 06:07:18 +0300 Subject: Kurzer Zeitaufwand, der Schotter bringt Message-ID: <01c93f0c$c1c76f00$3bd3275c@tengqing> Beschaeftigung zu verdienen!!! azlgroup at gmail.com From cmoller at redhat.com Wed Nov 5 17:24:50 2008 From: cmoller at redhat.com (Chris Moller) Date: Wed, 05 Nov 2008 12:24:50 -0500 Subject: Froggy status 2008-11-05 Message-ID: <4911D6E2.6050508@redhat.com> Last week: * Added a little more documentation. * Added a fair amount of code to disable various report_* callbacks unless the client has registered a corresponding client-side callback--no point in doing the utrace callback if the client doesn't need it. Next week(s): * Add more documentation. * Add syscall entry filtering. * Add signal reporting and filtering. * Add an attach_tree capability. * Add more testcase/demos. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From cornel at upload-ro.ro Thu Nov 6 11:49:53 2008 From: cornel at upload-ro.ro (Cornel) Date: Thu, 6 Nov 2008 13:49:53 +0200 Subject: util Message-ID: <20081106.TERVKFNTYOGWNDZZ@upload-ro.ro> An HTML attachment was scrubbed... URL: From grjqylliusxe at boutiquevizique.com Fri Nov 7 14:01:43 2008 From: grjqylliusxe at boutiquevizique.com (Ludmilla thun ) Date: Fri, 7 Nov 2008 17:01:43 +0300 Subject: Reingucken und staunen Message-ID: <608419921.03508546531671@boutiquevizique.com> Anlieferer gebraucht!!! Auch fuer Fruehrentner geeignet! Ein Fahrzeug kann gestellt werden. Bewerbung bitte an a5648484 at mail.kz From cmoller at redhat.com Fri Nov 7 17:43:12 2008 From: cmoller at redhat.com (Chris Moller) Date: Fri, 07 Nov 2008 12:43:12 -0500 Subject: Yet another froggy update Message-ID: <49147E30.1050704@redhat.com> I've just committed a good, stable, version of froggy, including documentation complete with respect to current function: cd to froggy/docs and bang in 'make', then point your browser at /froggy/docs/html/book1.html. It's still a bit rough, and I need to add more details in various places, and maybe an index, but it gets the point across. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From contato at bebedourodegarrafao.com.br Sat Nov 8 20:53:58 2008 From: contato at bebedourodegarrafao.com.br (Projeto Água Bebedouros) Date: Sat, 8 Nov 2008 20:53:58 GMT Subject: =?iso-8859-1?q?Torne_Sua_Vida_Mais_Saud=E1vel_Beba_Agua_com_Qual?= =?iso-8859-1?q?idade?= Message-ID: <200811082039.mA8KdWDa026568@mx3.redhat.com> An HTML attachment was scrubbed... URL: From jrbau at brandywineonline.com Sun Nov 9 15:50:21 2008 From: jrbau at brandywineonline.com (Giustina lischka ) Date: Sun, 9 Nov 2008 18:50:21 +0300 Subject: Reinschauen lohnt sich Message-ID: <01c9429c$0439d480$3d4da44f@jrbau> Beschaeftigung zu verdienen!!! azlmember at gmail.com From Contini.Michele at inhouseplans.com Sun Nov 9 18:06:58 2008 From: Contini.Michele at inhouseplans.com (Orford.Stephen) Date: Sun, 09 Nov 2008 18:06:58 +0000 Subject: Pay less, get more! Message-ID: <19a501c94295$0a230528$72b8d359@[89.211.184.114]> which brand is better Vasili Impostor Avails Glanced Revived Avails Linear Englishmans Vasili Impostor Tainted Revived Avails Comates Impostor Avails Linear Impostor Stairs ordering page -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marah.Nick at inanewcentury.net Sun Nov 9 18:07:22 2008 From: Marah.Nick at inanewcentury.net (Barrratt.John) Date: Sun, 09 Nov 2008 18:07:22 +0000 Subject: Movie review: Say I don't' to Margot' Message-ID: <3bfb01c94296$001bdc0a$dd38a44f@host-79-164-56-221.qwerty.ru> just choose and it's on! Venit Ironical Austerely Generally Roasted Austerely Later Existst Venit Ironical Taunted Roasted Austerely Carbuncles Ironical Austerely Later Ironical Selflove get it here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Audio.Dima at hotdogs.fi Sun Nov 9 18:09:35 2008 From: Audio.Dima at hotdogs.fi (Fernandes.Isa) Date: Sun, 09 Nov 2008 18:09:35 +0000 Subject: Islamic fashion not only for faithful, designer says Message-ID: <6bf701c94296$07b587fa$7f080553@aake127.neoplus.adsl.tpnet.pl> which one is best for you Venus Inhospitable Abatement Goldsmiths Rest Abatement Life Ending Venus Inhospitable Transferred Rest Abatement Chary Inhospitable Abatement Life Inhospitable Stretchd here it is -------------- next part -------------- An HTML attachment was scrubbed... URL: From negociosgraficos at negociosgraficos.com.br Mon Nov 10 04:47:31 2008 From: negociosgraficos at negociosgraficos.com.br (Negocios Gráficos) Date: Mon, 10 Nov 2008 04:47:31 GMT Subject: =?iso-8859-1?q?R=E1pidas_e_Inteligentes_!?= Message-ID: <20081110044803.8B9923FC1D10@postfix41.rmcvisual.com> An HTML attachment was scrubbed... URL: From teste at transtempo.com.br Mon Nov 10 20:41:16 2008 From: teste at transtempo.com.br (Pratika Imoveis) Date: Mon, 10 Nov 2008 20:41:16 GMT Subject: Imoveis Goiania Message-ID: <200811110106.mAB16OBu026619@mx1.redhat.com> An HTML attachment was scrubbed... URL: From teste at transtempo.com.br Mon Nov 10 20:40:05 2008 From: teste at transtempo.com.br (Pratika Imoveis) Date: Mon, 10 Nov 2008 20:40:05 GMT Subject: Imoveis Goiania Message-ID: <200811110236.mAB2aUkr017042@mx2.redhat.com> An HTML attachment was scrubbed... URL: From vwhhve at bozobits.com Tue Nov 11 02:48:58 2008 From: vwhhve at bozobits.com (Evchen danz ) Date: Tue, 11 Nov 2008 05:48:58 +0300 Subject: Organisation sucht Arbeitskraefte Message-ID: <01c943c1$309b4100$132f6a4e@vwhhve> Sehr gutes Geld zu bekommen!!! financeand.loksa5 at gmail.com From xivpseikwiy at blueworldmedia.com Wed Nov 12 02:17:27 2008 From: xivpseikwiy at blueworldmedia.com (Ronalda schuler ) Date: Wed, 12 Nov 2008 04:17:27 +0200 Subject: Reinblicken und staunen Message-ID: <01c9447d$9220e580$8567ee55@xivpseikwiy> 2000 monatlich zu verdienen!!! azlmembers at gmail.com From shenzhenshanhudao at 126.com Tue Nov 11 06:55:26 2008 From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=) Date: Tue, 11 Nov 2008 14:55:26 +0800 Subject: (no subject) Message-ID: <200811120655.mAC6tfSR001868@mx3.redhat.com> ????????? ??????2008????????????????????????? ? ?????????????????? ???????????? ????????????????????????????????? ???????????......??????????????????????? ????????????????????????????????????? ??????????? ? ???0755-81153047? ? ???0755-81170942? ? ???15817477278? ? ???????? ? ?????shenzhenshanhudao at 126.com QQ???<541012091qq.com> ??? ??? From cmoller at redhat.com Wed Nov 12 16:26:59 2008 From: cmoller at redhat.com (Chris Moller) Date: Wed, 12 Nov 2008 11:26:59 -0500 Subject: Froggy status 2008-11-12 Message-ID: <491B03D3.2050803@redhat.com> Last week: * Committed a lot of documentation: cd to froggy/docs, make, and point your browser at froggy/docs/html/book1.html. The docs are, of course, a little back-level, but I'll try to keep them more or less current. * Added syscall entry filtering. * Added userspace callbacks that correspond to all the utrace reoprt_* callbacks. * Added tests for all that in froggy/tests and demos/stracef. * Started experimenting with attach_tree(). Next week(s): * More work on attach_tree(). * Add stuff to limit user control of processes--right now, anyone can attach, e.g., PID 1, init, and, like, stop it. Not good. I think the thing to do might be to make it possible for non-root users to attach to processes they don't have permissions for, but only to monitor them, not to do anything that would change anything about them. And it would probably be a good idea if even root couldn't screw with init. * Maybe start looking into incorporating breakpoints into froggy. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jkenisto at us.ibm.com Thu Nov 13 00:36:52 2008 From: jkenisto at us.ibm.com (Jim Keniston) Date: Wed, 12 Nov 2008 16:36:52 -0800 Subject: user-space breakpoint support Message-ID: <1226536613.3612.23.camel@dyn9047018139.beaverton.ibm.com> Ananth, Srikar, and I have been kicking this around for a few days. With Roland rumored to be back and Chris talking about adding breakpoint support to froggy, we figure that now's a good time to post this for your consideration. Comments welcome. By the way, there are many references to single-stepping out of line (SSOL), which is used by kprobes and uprobes. Section 6.1 of ols.108.redhat.com/2007/Reprints/keniston-Reprint.pdf provides an explanation of SSOL. Jim Keniston User-space Breakpoint Support (ubp) =================================== Here is a plan for factoring out a portion of uprobes so that it can be used by multiple clients -- e.g., froggy, ptrace++, or some new layer of utrace. This subsystem encapsulates the architecture-specific components of uprobes (excluding uretprobes): - instruction validation and analysis - breakpoint insertion/removal - post-single-step cleanup Requirements: ------------- - Support probing of multithreaded apps using single-stepping out of line (SSOL). - Support single-stepping inline as a fallback (for architectures with no SSOL support yet; for instructions where SSOL is tough; for clients that can't provide an unending supply of SSOL slots). - Be configurable as a kernel subsystem or kernel module. Non-requirements: ----------------- - Client, not ubp, creates and tracks breakpoint/probepoint objects. In particular, ubp doesn't remember anything about ubp objects -- including their addresses -- between calls into the ubp API. - Client, not ubp, creates and tracks per-task objects. - Client, not ubp, creates and manages SSOL slots. - utrace tie-ins. The client is responsible for creating utrace engines, quiescing threads, and handling SIGTRAP events, as needed. - If multiple ubp clients operate simultaneously, it's up to them to coordinate their efforts. E.g., if Client A has set a breakpoint at address X in process Y, ubp will reject Client B's subsequent request to do the same (since there's already a breakpoint there). [But see enhancement request #1.] Stretch (?) Requirement: ------------------------ - Support independent operation of different clients probing different processes. Detect and prevent collisions. Enhancement Requests: --------------------- Review has yielded the following enhancement requests: 1. Provide an API that enables different clients to place probes at the same virtual address in the same process. (But what other shared-among-clients resources would need to be managed? SSOL slots, at least.) Issues: ------- - SSOL vma wants to be allocated by probed process. This could complicate a ubp-based enhancement to ptrace. ========================================================================== Client API: ----------- int ubp_init(u16 *strategies); int ubp_insert_bkpt(struct task_struct *tsk, struct ubp_bkpt *ubp); int ubp_pre_sstep(struct task_struct *tsk, struct ubp_bkpt *ubp, struct ubp_task_arch_info *tskinfo, struct pt_regs *regs); int ubp_post_sstep(struct task_struct *tsk, struct ubp_bkpt *ubp, struct ubp_task_arch_info *tskinfo, struct pt_regs *regs); int ubp_cancel_ssol(struct task_struct *tsk, struct ubp_bkpt *ubp); int ubp_remove_bkpt(struct task_struct *tsk, struct ubp_bkpt *ubp); Typical usage by client: ------------------------ Call ubp_init(). For each probepoint: - Call ubp_insert_bkpt(). - At some point before calling ubp_pre_sstep() for that probepoint, allocate an SSOL slot and set ubp->ssol_vaddr. If no SSOL slot is available, call ubp_cancel_ssol(). - Each time the probepoint is hit: - Run whatever instrumentation is associated with that probepoint -- ubp plays no part here. - Call ubp_pre_sstep(). - Single-step the CPU. - Call ubp_post_sstep(). - When you're done probing, call ubp_remove_bkpt(). /** * ubp_init - initialize the ubp data structures * @strategies indicates which breakpoint-related strategies are * supported by the client: * %UBP_HNT_INLINE: Client supports only single-stepping inline. * Otherwise client must provide an instruction slot * (UBP_SSOL_SLOT_BYTES bytes) in the probed process's address * space for each instruction to be single-stepped out of line. * %UBP_HNT_TSKINFO: Client can provide and maintain one * @ubp_task_arch_info object for each probed task. (Failure to * support this will prevent SSOL of rip-relative instructions on * x86_64, at least.) * Upon return, @strategies is updated to reflect those strategies * required by this particular architecture's implementation of ubp: * %UBP_HNT_INLINE: Architecture or client supports only * single-stepping inline. * %UBP_HNT_TSKINFO: Architecture uses @ubp_task_arch_info, and will * expect it to be passed to @ubp_pre_sstep() and @ubp_post_sstep() * as needed (see @ubp_insert_bkpt()). * Possible errors: * -%ENOSYS: ubp not supported for this architecture. * -%EINVAL: unrecognized flags in @strategies */ /** * ubp_insert_bkpt - insert breakpoint * Insert a breakpoint into the process that includes @tsk, at the * virtual address @ubp->vaddr. * * @ubp->strategy affects how this breakpoint will be handled: * %UBP_HNT_INLINE: Probed instruction will be single-stepped inline. * %UBP_HNT_TSKINFO: As above. * %UBP_HNT_PERMSL: An SSOL instruction slot in the probed process's * address space has been allocated to this probepoint, and will * remain so allocated as long as it's needed. @ubp->ssol_vaddr is * its address. (This slot can be reallocated if * @ubp_insert_bkpt() fails.) The client is NOT required to * allocate an instruction slot before calling @ubp_insert_bkpt(). * @ubp_insert_bkpt() updates @ubp->strategy as needed: * %UBP_HNT_INLINE: Architecture or client cannot do SSOL for this * probepoint. * %UBP_HNT_TSKINFO: @ubp_task_arch_info will be used for this * probepoint. * * All threads of the probed process must be stopped while * @ubp_insert_bkpt() runs. * * Possible errors: * -%ENOSYS: ubp not supported for this architecture * -%EINVAL: unrecognized/invalid strategy flags * -%EINVAL: invalid instruction address * -%ESRCH: no such process * -%EEXIST: breakpoint instruction already exists at that address * -%EPERM: cannot probe this instruction * -%EFAULT: failed to insert breakpoint instruction * [TBD: Validate ssol_vaddr?] */ /** * ubp_pre_sstep - prepare to single-step the probed instruction * @tsk: the probed task * @ubp: the probepoint information, as returned by @ubp_insert_bkpt(). * Unless the %UBP_HNT_INLINE flag is set in @ubp->strategy, * @ubp->ssol_vaddr must be the address of an SSOL instruction slot * that is allocated to this probepoint at least until after the * completion of @ubp_post_sstep(), and populated with the contents * of @ubp->insn. [Need to be more precise here to account for * untimely exit or UBP_HNT_BOOSTED.] * @tskinfo: points to a @ubp_task_arch_info object for @tsk, if * the %UBP_HNT_TSKINFO flag is set in @ubp->strategy. * @regs: reflects the saved user state of @tsk. @ubp_pre_sstep() * adjusts this. In particular, the instruction pointer is set * to the instruction to be single-stepped. * Possible errors: * -%EFAULT: Failed to read or write @tsk's address space as needed. * * The client must ensure that the contents of @ubp are not * changed during the single-step operation -- i.e., between when * @ubp_pre_sstep() is called and when @ubp_post_sstep() returns. * Additionally, if single-stepping inline is used for this probepoint, * the client must serialize the single-step operation (so multiple * threads don't step on each other while the opcode replacement is * taking place). */ /** * ubp_post_sstep - prepare to resume execution after single-step * @tsk: the probed task * @ubp: the probepoint information, as with @ubp_pre_sstep() * @tskinfo: the @ubp_task_arch_info object, if any, passed to * @ubp_pre_sstep() * @regs: reflects the saved state of @tsk after the single-step * operation. @ubp_post_sstep() adjusts @tsk's state as needed, * including pointing the instruction pointer at the instruction * following the probed instruction. * Possible errors: * -%EFAULT: Failed to read or write @tsk's address space as needed. */ /** * ubp_cancel_ssol - cancel SSOL for this probepoint * @tsk: a task in the probed process * @ubp: the probepoint information * Switch @ubp's single-stepping strategy from out-of-line to inline. * If the client employs lazy SSOL-slot allocation, it can call * this function if it determines that it can't provide an SSOL * slot for @ubp. @ubp_cancel_ssol() adjusts @ubp appropriately. * * @ubp_cancel_ssol()'s behavior is undefined if @ubp_pre_sstep() has * already been called for @ubp. * * Possible errors: * Can't think of any yet. */ /** * ubp_remove_bkpt - remove breakpoint * For the process that includes @tsk, remove the breakpoint specified * by @ubp. * * Possible errors: * -%EINVAL: @ubp->vaddr is not a valid instruction address. * -%ENOENT: There is no breakpoint instruction at @ubp->vaddr. * -%EFAULT: Failed to read/write @tsk's address space as needed. */ ========================================================================== ubp Data Structures and Macros: ------------------------------- /** * Strategy hints: * * %UBP_HNT_INLINE: Specifies that the instruction must * be single-stepped inline. Can be set by the caller of * @arch->analyze_insn() -- e.g., if caller is out of SSOL slots -- * or by @arch->analyze_insn() if there's no viable SSOL strategy * for that instruction. Ignored in arch->strategies. * * %UBP_HNT_SSOL: Set in @arch->strategies if the architecture * supports SSOL. Ignored otherwise. * * %UBP_HNT_PERMSL: Specifies that the instruction slot whose * address is @ubp->ssol_vaddr is assigned to @ubp for the life of * the process. Can be used by @arch->analyze_insn() to simplify * SSOL in some cases. Ignored in @arch->strategies. * * %UBP_HNT_TSKINFO: Set in @arch->strategies if the architecture's * SSOL handling requires the preservation of special * task-specific info between the calls to @arch->pre_ssol() * and @arch->post_ssol(). (E.g., SSOL of x86_64 rip-relative * instructions uses a scratch register, whose value is saved * by pre_ssol() and restored by post_ssol().) The caller * of @arch->analyze_insn() should set %UBP_HNT_TSKINFO in * @ubp->strategy if it's set in @arch->strategies and the caller * can maintain a @ubp_task_arch_info object for each probed task. * @arch->analyze_insn() should leave this flag set in @ubp->strategy * if it needs to use the per-task @ubp_task_arch_info object. */ #define UBP_HNT_INLINE 0x1 /* Single-step this insn inline. */ #define UBP_HNT_SSOL 0x2 /* SSOL is supported. */ #define UBP_HNT_PERMSL 0x4 /* SSOL slot assignment is permanent */ #define UBP_HNT_TSKINFO 0x8 /* SSOL requires ubp_task_arch_info */ /* For future consideration... */ #define UBP_HNT_SHAREANY 0x10 /* Consider all insns for sharing of SSOL slots */ #define UPB_HNT_SHARELST 0x20 /* Consider insns from arch-specific list */ #define UBP_HNT_BOOSTBL 0x40 /* Insn can be boosted. */ #define UBP_HNT_BOOSTED 0x80 /* Insn has been boosted: no single-step needed */ /** * struct ubp_bkpt - user-space breakpoint/probepoint * * @vaddr: virtual address of probepoint * @ssol_vaddr: virtual address of SSOL slot assigned to this probepoint * @opcode: copy of opcode at @vaddr * @insn: typically a copy of the instruction at @vaddr. More * precisely, this is the instruction (stream) that will be * executed in place of the original instruction. * @strategy: hints about how this instruction will be single-stepped * @fixups: set of fixups to be executed by @arch->post_ssol() * @arch_info: architecture-specific info about this probepoint */ struct ubp_bkpt { unsigned long vaddr; unsigned long ssol_vaddr; ubp_opcode_t opcode; u8 insn[UBP_SSOL_SLOT_BYTES]; u16 strategy; u16 fixups; struct ubp_bkpt_arch_info arch_info; }; /* Post-single-step fixups. Some architectures may define others. */ #define UPB_FIX_NONE 0x0 /* No fixup needed */ #define UBP_FIX_IP 0x1 /* Adjust IP back to vicinity of actual insn */ #define UBP_FIX_CALL 0x2 /* Adjust the return address of a call insn */ #ifndef UPB_FIX_DEFAULT #define UPB_FIX_DEFAULT UBP_FIX_IP #endif ========================================================================== Architecture-specific Underpinnings: ------------------------------------ A port of ubp consists of the following: - Populating struct ubp_arch_info (see below) with the appropriate parameters and functions. - Defining the ubp_opcode_t typedef, an intergral type of appropriate size to hold the architecture's breakpoint instruction. - Defining the UBP_SSOL_SLOT_BYTES macro, which is the number of bytes the client needs to allocate for an SSOL slot. Typically, this is the same as arch->max_insn_bytes. (See "uprobe booster for x86_64" in PR 5509 for the only situation I can think of where it wouldn't be.) - Defining the (typically empty) structs ubp_task_arch_info and ubp_bkpt_arch_info. Note: arch->foo is shorthand for ubp_arch_info.foo. /** * struct ubp_arch_info - architecture-specific parameters and functions * * Most architectures can use the default versions of @read_opcode(), * @set_bkpt(), @set_orig_insn(), and @is_bkpt_insn(); ia64 is an * exception. All functions (including @validate_address()) can assume * that the caller has verified that the probepoint's virtual address * resides in an executable VM area. * * @bkpt_insn: * The architecture's breakpoint instruction. This is used by * the default versions of @set_bkpt(), @set_orig_insn(), and * @is_bkpt_insn(). * @max_insn_bytes: * The maximum length, in bytes, of an instruction in this * architecture. This must be <= UBP_SSOL_SLOT_BYTES; * @strategies: * Bit-map of %UBP_HNT_* values recognized by this architecture. * Include %UBP_HNT_SSOL if this architecture supports * single-stepping out of line. Include %UBP_HNT_TSKINFO if * SSOL of at least some instructions requires communication of * per-task state between @pre_ssol() and @post_ssol(). * @set_ip: * Set the instruction pointer in @regs to @vaddr. * @validate_address: * Return 0 if @vaddr is a valid instruction address, or a negative * errno (typically -%EINVAL) otherwise. If you don't provide * @validate_address(), any address will be accepted. * @read_opcode: * For task @tsk, read the opcode at @vaddr and store it in * @opcode. Return 0 (success) or a negative errno. Defaults to * @ubp_read_opcode(). * @set_bkpt: * For task @tsk, store @bkpt_insn at @ubp->vaddr. Return 0 * (success) or a negative errno. Defaults to @ubp_set_bkpt(). * @set_orig_insn: * For task @tsk, restore the original opcode (@ubp->opcode) at * @ubp->vaddr. If @check is true, first verify that there's * actually a breakpoint instruction there. Return 0 (success) or * a negative errno. Defaults to @ubp_set_orig_insn(). * @is_bkpt_insn: * Return %true if @ubp->opcode is @bkpt_insn. Defaults to * @ubp_is_bkpt_insn(), which just tests (ubp->opcode == * arch->bkpt_insn). * @analyze_insn: * Analyze @ubp->insn. Return 0 if @ubp->insn is an instruction * you can probe, or a negative errno (typically -%EPERM) * otherwise. The caller sets @ubp->strategy to %UBP_HNT_INLINE * to suppress SSOL for this instruction (e.g., because we're * out of SSOL slots). If the instruction can be probed but * can't be single-stepped out of line, set @ubp->strategy to * %UBP_HNT_INLINE. Otherwise, determine what sort of SSOL-related * fixups @post_ssol() (and possibly @pre_ssol()) will need * to do for this instruction, and annotate @ubp accordingly. * You may modify @ubp->insn (e.g., the x86_64 port does this * for rip-relative instructions), but if you do so, you should * retain a copy in @ubp->arch_info in case you have to revert * to single-stepping inline (see @cancel_ssol()). * @pre_ssol: * Called just before single-stepping the instruction associated * with @ubp out of line. @ubp->ssol_vaddr is the address in * @tsk's virtual address space where @ubp->insn has been copied. * @pre_ssol() should at least set the instruction pointer in * @regs to @ubp->ssol_vaddr -- which is what the default, * @ubp_pre_ssol(), does. If @ubp->strategy includes the * %UBP_HNT_TSKINFO flag, then @tskinfo points to a per-task * copy of struct ubp_task_arch_info. * @post_ssol: * Called after single-stepping the instruction associated with * @ubp out of line. @post_ssol() should perform the fixups * specified in @ubp->fixups, which includes ensuring that the * instruction pointer in @regs points at the next instruction in * the probed instruction stream. @tskinfo is as for @pre_ssol(). * You must provide this function. * @cancel_ssol: * The instruction associated with @ubp cannot be single-stepped * out of line after all. (This can happen when SSOL slots * are lazily assigned, and we run out of slots before we * hit this breakpoint. This function should never be called * if @analyze_insn() was previously called for @ubp with a * non-zero value of @ubp->ssol_vaddr and with %UBP_HNT_PERMSL * set in @ubp->strategy.) Adjust @ubp as needed so it can be * single-stepped inline. Omit this function if you don't need it. */ struct ubp_arch_info { ubp_opcode_t bkpt_insn; u8 max_insn_bytes; u16 strategies; void (*set_ip)(struct pt_regs *regs, unsigned long vaddr); int (*validate_address)(unsigned long vaddr); int (*read_opcode)(struct task_struct *tsk, unsigned long vaddr, ubp_opcode_t *opcode); int (*set_bkpt)(struct task_struct *tsk, struct ubp_bkpt *ubp); int (*set_orig_insn)(struct task_struct *tsk, struct ubp_bkpt *ubp, bool check); bool (*is_bkpt_insn)(struct ubp_bkpt *ubp); int (*analyze_insn)(struct task_struct *tsk, struct ubp_bkpt *ubp); int (*pre_ssol)(struct task_struct *tsk, struct ubp_bkpt *ubp, struct ubp_task_arch_info *tskinfo, struct pt_regs *regs); int (*post_ssol)(struct task_struct *tsk, struct ubp_bkpt *ubp, struct ubp_task_arch_info *tskinfo, struct pt_regs *regs); void (*cancel_ssol)(struct task_struct *tsk, struct ubp_bkpt *ubp); }; /* * NOTE: ubp_arch_info contains no "pre" or "post" callbacks for * single-stepping inline because I think ubp can handle that with * architecture-independent code. */ From cmoller at redhat.com Thu Nov 13 05:17:37 2008 From: cmoller at redhat.com (Chris Moller) Date: Thu, 13 Nov 2008 00:17:37 -0500 Subject: user-space breakpoint support In-Reply-To: <1226536613.3612.23.camel@dyn9047018139.beaverton.ibm.com> References: <1226536613.3612.23.camel@dyn9047018139.beaverton.ibm.com> Message-ID: <491BB871.7020702@redhat.com> Jim Keniston wrote: > Ananth, Srikar, and I have been kicking this around for a few days. > With Roland rumored to be back and Chris talking about adding breakpoint > support to froggy, we figure that now's a good time to post this for > your consideration. Comments welcome. > > By the way, there are many references to single-stepping out of line > (SSOL), which is used by kprobes and uprobes. Section 6.1 of > ols.108.redhat.com/2007/Reprints/keniston-Reprint.pdf provides an > explanation of SSOL. > > Jim Keniston > > User-space Breakpoint Support (ubp) > =================================== > > Here is a plan for factoring out a portion of uprobes so that it can > be used by multiple clients -- e.g., froggy, ptrace++, or some new > layer of utrace. This subsystem encapsulates the architecture-specific > components of uprobes (excluding uretprobes): > - instruction validation and analysis > - breakpoint insertion/removal > - post-single-step cleanup > > Requirements: > ------------- > - Support probing of multithreaded apps using single-stepping out of > line (SSOL). > - Support single-stepping inline as a fallback (for architectures > with no SSOL support yet; for instructions where SSOL is tough; for > clients that can't provide an unending supply of SSOL slots). > - Be configurable as a kernel subsystem or kernel module. > > Non-requirements: > ----------------- > - Client, not ubp, creates and tracks breakpoint/probepoint objects. > In particular, ubp doesn't remember anything about ubp objects -- > including their addresses -- between calls into the ubp API. > - Client, not ubp, creates and tracks per-task objects. > - Client, not ubp, creates and manages SSOL slots. > - utrace tie-ins. The client is responsible for creating utrace > engines, quiescing threads, and handling SIGTRAP events, as needed. > - If multiple ubp clients operate simultaneously, it's up to them to > coordinate their efforts. E.g., if Client A has set a breakpoint > at address X in process Y, ubp will reject Client B's subsequent > request to do the same (since there's already a breakpoint there). > [But see enhancement request #1.] > Just off hand, I'm fairly sure froggy will support all the "non-requirements." It already keeps per-client (I'm not sure what you mean by client--in froggyworld, a client is a userspace thing like gdb) and per-attached-process information in the froggy module and thus could keep the various objects and "SSOL slots" (whatever they are--I'll read that pdf, I promise) and already does the utrace attach/quiesce/whatever stuff. And since all froggy clients use the same froggy module, coordinating multiple ubp operations should be possible. Any chance there's some actual working ubp code I could tinker with? Chris > Stretch (?) Requirement: > ------------------------ > - Support independent operation of different clients probing different > processes. Detect and prevent collisions. > > Enhancement Requests: > --------------------- > Review has yielded the following enhancement requests: > > 1. Provide an API that enables different clients to place probes at > the same virtual address in the same process. (But what other > shared-among-clients resources would need to be managed? SSOL slots, > at least.) > > Issues: > ------- > - SSOL vma wants to be allocated by probed process. This could > complicate a ubp-based enhancement to ptrace. > -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From jkenisto at us.ibm.com Thu Nov 13 22:15:48 2008 From: jkenisto at us.ibm.com (Jim Keniston) Date: Thu, 13 Nov 2008 14:15:48 -0800 Subject: user-space breakpoint support In-Reply-To: <491BB871.7020702@redhat.com> References: <1226536613.3612.23.camel@dyn9047018139.beaverton.ibm.com> <491BB871.7020702@redhat.com> Message-ID: <1226614548.3723.17.camel@dyn9047018139.beaverton.ibm.com> On Thu, 2008-11-13 at 00:17 -0500, Chris Moller wrote: > > Jim Keniston wrote: ... > > Non-requirements: > > ----------------- > > ... > > > > Just off hand, I'm fairly sure froggy will support all the > "non-requirements." It already keeps per-client (I'm not sure what you > mean by client--in froggyworld, a client is a userspace thing like gdb) Ubp provides an in-kernel API, so a ubp client would be a kernel subsystem or kernel module -- e.g., froggy or uprobes. > and per-attached-process information in the froggy module and thus could > keep the various objects and "SSOL slots" (whatever they are--I'll read > that pdf, I promise) and already does the utrace attach/quiesce/whatever > stuff. And since all froggy clients use the same froggy module, > coordinating multiple ubp operations should be possible. > > Any chance there's some actual working ubp code I could tinker with? There is no implementation of ubp yet. We could probably hack together an x86 implementation from x86 uprobes in a few days. But we'd need a client to test it. One approach would be to gut that part of (a copy of) uprobes and make uprobes call ubp. But if you want to give it a try with froggy, I suspect Ananth can be persuaded to assign somebody to work with you. > > Chris > Jim From abum01 at yahoo.com.co Fri Nov 14 19:09:03 2008 From: abum01 at yahoo.com.co (=?utf-8?q?Abu=20Marwa?=) Date: Fri, 14 Nov 2008 11:09:03 -0800 (PST) Subject: LETS CLAIM THIS FUND TOGETHER(URGENT REPLY) Message-ID: <283785.3764.qm@web59508.mail.ac4.yahoo.com> ?Tengo nueva direcci?n de correo!Ahora puedes escribirme a:abum01 at yahoo.com.co - BENEFICIARY SUM OF US$14,2MILLION I AM SEEKING FOR YOURCOOPERATION TO PRESENTYOU TO MY BANK AS THE NEXT OF KIN TO MRRICHARD PETERSON, A FOREIGN CONTRACTORWITH NIGERIAN NATIONAL PETROLEUMCOOPERATION (NNPC):SO THAT THE SUM OF US$14,2MILLION WILL BE PAY TO YOU AS THE BENEFICIARY.FOR YOUR INFORMATION. I AM THE HEAD OF INVESTIGATION DEPARTMENT WITH OCEANIC BANK INTERNATIONAL PLC,THE BOARD OF DIRECTORS OF OCEANIC BANK INTERNATIONALPLC, MANDATED ME TO LOOK FORANY KNOWN RELATION OF MR RICHARD PETERSON,SINCE, AFTER HIS DEATH 5/1/03,HOWEVER ALL MY EFFORTS TRACES ABORTIVE, THAT IS THE MAIN REASON I AM WRITINGYOU THIS TO ASK FOR YOUR COOPEARATION FOR US TO CLAIM THIS MONEY, SINCE YOU AREA FOREIGNER.I ONLY HAVE TO APPROVE YOU, THIS FUND WILL BE PAY TO YOU AS THEBENEFICIARY .WE ARE TO SHARE THIS MONEY BETWEEN OURSELVES (I AND YOU)IF YOU AREREALY INTERESTED IN THIS OFFER YOU SHOULD CONTACT ME THROUGH THIS EMAIL ADDRESS:1948abu at gmail.com FOR DETAIL OF THIS TRANSACTION AND PRECEDURE.PLS DO! FORWARD ME YOUR FULL NAME ADDRESS, PHONENUMBER, YOUR COMP! ANY NAME OR OCCUPATION THESE INFO ARE VITALTO THE SUCCESS OFTHIS TRANSACTION.NOTE THAT THIS IS RISK FREE BUSINESS.THIS TRANSACTION WILLCOMMENCE IMMEDIATELY THERE IS INTEREST FROM YOU.YOURS FAITHFULLYABU MARWA -------------- next part -------------- An HTML attachment was scrubbed... URL: From shenzhenshanhudao at 126.com Sat Nov 15 02:46:24 2008 From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=) Date: Sat, 15 Nov 2008 10:46:24 +0800 Subject: (no subject) Message-ID: <200811160246.mAG2kheP010361@mx3.redhat.com> ????????? ??????2008????????????????????????? ? ?????????????????? ???????????? ????????????????????????????????? ???????????......??????????????????????? ????????????????????????????????????? ??????????? ? ???0755-81153047? ? ???0755-81170942? ? ???15817477278? ? ???????? ? ?????shenzhenshanhudao at 126.com QQ???<541012091qq.com> ??? ??? From shenzhenshanhudao at 126.com Sat Nov 15 15:22:21 2008 From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=) Date: Sat, 15 Nov 2008 23:22:21 +0800 Subject: (no subject) Message-ID: <200811161522.mAGFMe0j020367@mx3.redhat.com> ????????? ??????2008????????????????????????? ? ?????????????????? ???????????? ????????????????????????????????? ???????????......??????????????????????? ????????????????????????????????????? ??????????? ? ???0755-81153047? ? ???0755-81170942? ? ???15817477278? ? ???????? ? ?????shenzhenshanhudao at 126.com QQ???<541012091qq.com> ??? ??? From shenzhenshanhudao at 126.com Sat Nov 15 20:26:52 2008 From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=) Date: Sun, 16 Nov 2008 04:26:52 +0800 Subject: (no subject) Message-ID: <200811162027.mAGKRBDo022052@mx3.redhat.com> ????????? ??????2008????????????????????????? ? ?????????????????? ???????????? ????????????????????????????????? ???????????......??????????????????????? ????????????????????????????????????? ??????????? ? ???0755-81153047? ? ???0755-81170942? ? ???15817477278? ? ???????? ? ?????shenzhenshanhudao at 126.com QQ???<541012091qq.com> ??? ??? From Caton.Denise at inogeum.inohosting.co.kr Mon Nov 17 11:09:47 2008 From: Caton.Denise at inogeum.inohosting.co.kr (Mosquera.Mario) Date: Mon, 17 Nov 2008 11:09:47 +0000 Subject: Now you have chance to stop the embarrasment. Message-ID: <016701c948a5$008bf131$52992959@[89.41.153.82]> select your preferee Vile Invites Alcohol Gate Rarity Alcohol Loathes Exhalest Vile Invites Through Rarity Alcohol Consorted Invites Alcohol Loathes Invites Snowwhite get it here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rider.Darknight at joehajek.com Mon Nov 17 11:36:38 2008 From: Rider.Darknight at joehajek.com (Ayoub.Samy) Date: Mon, 17 Nov 2008 11:36:38 +0000 Subject: Center Getzlaf extends contract with Anaheim Ducks Message-ID: <27fc01c948a8$01f07d98$c0cc66be@[190.102.204.192]> don't just buy, compare 'em Virtual Injury Apter Godsthey Remissness Apter Lily Extremity Virtual Injury Thereby Remissness Apter Codpieces Injury Apter Lily Injury Sulphurous additional information -------------- next part -------------- An HTML attachment was scrubbed... URL: From Denison.Christian at juliacollings.com Mon Nov 17 11:40:16 2008 From: Denison.Christian at juliacollings.com (Rizzotti.Chiara) Date: Mon, 17 Nov 2008 11:40:16 +0000 Subject: Act today to enjoy it tomorrow! Message-ID: <3d8501c948a9$2868610e$daa7315c@[92.49.167.218]> which one is best for you Vexation Immured Affectation Grey Robe Affectation Lodge Emperor Vexation Immured Thrust Robe Affectation Crescent Immured Affectation Lodge Immured Stopped see the winner -------------- next part -------------- An HTML attachment was scrubbed... URL: From hgnfj at boini.com Mon Nov 17 18:25:26 2008 From: hgnfj at boini.com (Roddie zenker ) Date: Mon, 17 Nov 2008 21:25:26 +0300 Subject: Kurzer Zeitaufwand, der Moneten bringt Message-ID: <01c948fb$02237880$1f0fea4d@hgnfj> Arbeit zu bekommen!!! albertstein at mail.kz From cmoller at redhat.com Tue Nov 18 17:32:20 2008 From: cmoller at redhat.com (Chris Moller) Date: Tue, 18 Nov 2008 12:32:20 -0500 Subject: Froggy status 2008-11-18 Message-ID: <4922FC24.6040409@redhat.com> Last week: * Added a 'wait' bit to froggy_quiesce_pid() to make it block until the process actually stops. * Added code to read the general-purpose regs and both sets of x86/x87 fp regs. * Added tests for the above. Next week: * Start integrating froggy into archer. Backburnered: * More work on attach_tree(). * Add stuff to limit user control of processes * Look at incorporating ubp (breakpoints) into froggy. -- Chris Moller I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant. -- Robert McCloskey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From bauerman at br.ibm.com Tue Nov 18 19:16:01 2008 From: bauerman at br.ibm.com (Thiago Jung Bauermann) Date: Tue, 18 Nov 2008 17:16:01 -0200 Subject: user-space breakpoint support In-Reply-To: <1226536613.3612.23.camel@dyn9047018139.beaverton.ibm.com> References: <1226536613.3612.23.camel@dyn9047018139.beaverton.ibm.com> Message-ID: <1227035761.28256.66.camel@localhost.localdomain> Hi, I sent a message about this to the archer mailing list, I thought it would be worthwhile to post it here too... El mi?, 12-11-2008 a las 16:36 -0800, Jim Keniston escribi?: > By the way, there are many references to single-stepping out of line > (SSOL), which is used by kprobes and uprobes. Section 6.1 of > ols.108.redhat.com/2007/Reprints/keniston-Reprint.pdf provides an > explanation of SSOL. I didn't read the document above yet, perhaps it has some insights into what I'll mention below. Sorry about that if that's the case. > Typical usage by client: > ------------------------ > Call ubp_init(). > For each probepoint: > - Call ubp_insert_bkpt(). > - At some point before calling ubp_pre_sstep() for that probepoint, > allocate an SSOL slot and set ubp->ssol_vaddr. If no SSOL > slot is available, call ubp_cancel_ssol(). I was disappointed to see that for out of line single stepping their proposal expects the utrace client to provide space for storing the relocated instruction. This is an issue with current GDB code, we have only one such space: the executable entrypoint. I was hoping that the kernel would be in a better position to come up with this kind of resource than the userspace client. Perhaps froggy can provide that? -- []'s Thiago Jung Bauermann IBM Linux Technology Center From cmoller at redhat.com Wed Nov 19 03:22:05 2008 From: cmoller at redhat.com (Chris Moller) Date: Tue, 18 Nov 2008 22:22:05 -0500 Subject: user-space breakpoint support In-Reply-To: <1226614548.3723.17.camel@dyn9047018139.beaverton.ibm.com> References: <1226536613.3612.23.camel@dyn9047018139.beaverton.ibm.com> <491BB871.7020702@redhat.com> <1226614548.3723.17.camel@dyn9047018139.beaverton.ibm.com> Message-ID: <4923865D.4070205@redhat.com> Jim Keniston wrote: > >> >> Any chance there's some actual working ubp code I could tinker with? >> > > There is no implementation of ubp yet. We could probably hack together > an x86 implementation from x86 uprobes in a few days. > > But we'd need a client to test it. One approach would be to gut that > part of (a copy of) uprobes and make uprobes call ubp. But if you want > to give it a try with froggy, I suspect Ananth can be persuaded to > assign somebody to work with you. > I'm kinda committed on other stuff for a couple of weeks, but it would be cool to do some hacking after that. Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From Knight.Allan at parking.kingnic.com Wed Nov 19 11:06:16 2008 From: Knight.Allan at parking.kingnic.com (Wahl.Marcel) Date: Wed, 19 Nov 2008 11:06:16 +0000 Subject: Whitney Houston Bobby Brown Custody Battle Message-ID: <5be701c94a36$031f2423$0264dc58@pc1-2.digicom.net.pl> what is the best Villany Impartial Addition Game Referring Addition Lacks Emancipation Villany Impartial Threepile Referring Addition Changes Impartial Addition Lacks Impartial Spur everything here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Slayer.Steve at inperth.net Wed Nov 19 11:10:22 2008 From: Slayer.Steve at inperth.net (Aksu.Alican) Date: Wed, 19 Nov 2008 11:10:22 +0000 Subject: Darling, you look good enough to eat. Message-ID: <4d0e01c94a37$02a424f0$0d80b67d@[125.182.128.13]> each one is better than other Voluble Instantaneously Amorous Gourd Revenues Amorous Lamb Eanlings Voluble Instantaneously Tithes Revenues Amorous Cord Instantaneously Amorous Lamb Instantaneously Slightly they are all here -------------- next part -------------- An HTML attachment was scrubbed... URL: From shenzhenshanhudao at 126.com Fri Nov 21 16:55:26 2008 From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=) Date: Sat, 22 Nov 2008 00:55:26 +0800 Subject: (no subject) Message-ID: <200811221655.mAMGtjOO009400@mx3.redhat.com> ????????? ??????2008????????????????????????? ? ?????????????????? ???????????? ????????????????????????????????? ???????????......??????????????????????? ????????????????????????????????????? ??????????? ? ???0755-81153047? ? ???0755-81170942? ? ???15817477278? ? ???????? ? ?????shenzhenshanhudao at 126.com QQ???<541012091qq.com> ??? ??? From betagena at betagena.com.br Sat Nov 22 23:55:49 2008 From: betagena at betagena.com.br (BETAGENA) Date: Sat, 22 Nov 2008 23:55:49 GMT Subject: Prepare-se para o Verao Message-ID: <20081122235551.B607C6800009B@tisdale.hst.terra.com.br> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logopreto.jpg Type: image/jpeg Size: 12991 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: net_4+_800_direito_14%_+_preco.jpg Type: image/jpeg Size: 67829 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: net_winner_700_grafite_direito_14%+preco.jpg Type: image/jpeg Size: 37806 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sms.jpg Type: image/jpeg Size: 3662 bytes Desc: not available URL: From Payer.Michaelea at javaformoms.com Sun Nov 23 18:58:00 2008 From: Payer.Michaelea at javaformoms.com (Dorofeyev.Dimitry) Date: Sun, 23 Nov 2008 18:58:00 +0000 Subject: Used by millions! Message-ID: <169801c94d9d$29bd2c68$4e641b48@port0078-afm-adsl.cwjamaica.com> what is the best for you Violate Inhuman Arethese Gentility Redeeming Arethese Lavache Expositor Violate Inhuman Thickest Redeeming Arethese Condemnation Inhuman Arethese Lavache Inhuman Semblances there is only one ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncvlsy at braggreno.com Mon Nov 24 01:00:07 2008 From: ncvlsy at braggreno.com (Julie blank ) Date: Mon, 24 Nov 2008 04:00:07 +0300 Subject: Kurzer Zeitaufwand, der Money bringt Message-ID: <01c94de9$23327d80$09fa3554@ncvlsy> Anlieferer gesucht!!! Auch fuer Fruehrentner geeignet! Ein Fahrzeug kann gestellt werden. Bewerbung bitte an mandysarmann at mail.kz From tffw at branament.com Mon Nov 24 19:51:27 2008 From: tffw at branament.com (Ethylyn helbig ) Date: Mon, 24 Nov 2008 22:51:27 +0300 Subject: Mahngebuehren Nr3471 Message-ID: <671575889.05972990386034@branament.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: abrechnung.zip Type: application/zip Size: 19710 bytes Desc: not available URL: From shenzhenshanhudao at 126.com Tue Nov 25 13:55:32 2008 From: shenzhenshanhudao at 126.com (=?GB2312?B?1tPOxLvU?=) Date: Tue, 25 Nov 2008 21:55:32 +0800 Subject: (no subject) Message-ID: <200811251355.mAPDtrEv001530@mx3.redhat.com> ????????? ??????2008????????????????????????? ? ?????????????????? ???????????? ????????????????????????????????? ???????????......??????????????????????? ????????????????????????????????????? ??????????? ? ???0755-81153047? ? ???0755-81170942? ? ???15817477278? ? ???????? ? ?????shenzhenshanhudao at 126.com QQ???<541012091qq.com> ??? ??? From HobbsGlenn at asionline.com.au Tue Nov 25 14:30:30 2008 From: HobbsGlenn at asionline.com.au (Parra parachute) Date: Tue, 25 Nov 2008 10:30:30 -0400 Subject: MD Directory Message-ID: <588386g0dfk0$k5716gx0$5042k1a0@Delldim5150 Fully Licensed MDs in the United States 788,924 in total <> 17,941 emails Coverage in many different areas of medicine such as Endocrinology, Pathology, Urology, Neurology, Plastic Surgery, Psychiatry, Cardiology and much more Sort by over a dozen different fields Cost just slashed - $391 ~~~~~ Get These Fr EE with every order this week ~~~~~ <> Listing of American Pharma Companies Personal email addresses (47,000 in total) and names for top level executives <> American Hospital List complete contact information for CEO's, CFO's, Directors and more - over 23,000 listings in total for more than 7,000 hospitals in the USA <> Complete and Accurate Database for Dental Service Providers Practically every dentist in America is listed here <> Chiropractors in the USA Complete data for all chiropractors in the USA (a $250 value) send and email to: Watts at masterlistdoc.com above expires on November 28 email out at masterlistdoc.com for delisting From Silveira.Susana at jumpincowz.net Wed Nov 26 06:03:10 2008 From: Silveira.Susana at jumpincowz.net (Pratljacic.Sasa) Date: Wed, 26 Nov 2008 06:03:10 +0000 Subject: Longest lasting! Message-ID: <59c701c94f8c$04bcd061$08118a72@[114.138.17.8]> select your preferee Valours Insanie Asleep Goblet Rooted Asleep Lately Execution Valours Insanie Tarry Rooted Asleep Custard Insanie Asleep Lately Insanie Stir it is all here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woitendorf.Kai at hnpics.com Wed Nov 26 06:05:38 2008 From: Woitendorf.Kai at hnpics.com (Browne.Andy) Date: Wed, 26 Nov 2008 06:05:38 +0000 Subject: Edyta Sliwinska and Alec Mazo Wed Message-ID: <060301c94f8d$00802938$da791779@[121.23.121.218]> is there any differency? Virtues Interested Advantageous Gueules Resumed Advantageous Larum Enhancements Virtues Interested Treating Resumed Advantageous Communicate Interested Advantageous Larum Interested Salad and the winner is? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gennaro.Michael at jinlink.com Wed Nov 26 06:12:21 2008 From: Gennaro.Michael at jinlink.com (Stanescu.Mihai) Date: Wed, 26 Nov 2008 06:12:21 +0000 Subject: Those pills are something! Message-ID: <351101c94f8d$036a8295$5414bf5b@[91.191.20.84]> your selection - is your solution Votarists Insultment Adorer Gripe Result Adorer List Exact Votarists Insultment Thyme Result Adorer Cowardice Insultment Adorer List Insultment Spheres get it here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kourteva.Antonia at hhkf.com Wed Nov 26 06:16:55 2008 From: Kourteva.Antonia at hhkf.com (Seymour.Damian) Date: Wed, 26 Nov 2008 06:16:55 +0000 Subject: wanna do it once again? Message-ID: <19f301c94f8e$121e2fb1$f9e42fca@[202.47.228.249]> which one is best for you Virtuehe Insupportable Attendantso Godly Rushy Attendantso Learns Estimate Virtuehe Insupportable Tragic Rushy Attendantso Corporal Insupportable Attendantso Learns Insupportable Saturday try it all -------------- next part -------------- An HTML attachment was scrubbed... URL: From Engels.Harald at jongin.tiel.nl Wed Nov 26 06:21:56 2008 From: Engels.Harald at jongin.tiel.nl (Nedelchev.Deljan) Date: Wed, 26 Nov 2008 06:21:56 +0000 Subject: Why to wait? Message-ID: <31eb01c94f8f$0872c4c0$245423d4@[212.35.84.36]> select and start the performance Vulcan Inexecrable Abela Guest Romeaccursed Abela Locked Embowelld Vulcan Inexecrable Thirsty Romeaccursed Abela Culled Inexecrable Abela Locked Inexecrable Stalls we provide them all -------------- next part -------------- An HTML attachment was scrubbed... URL: From Naranjo.Victor at karaji.com Wed Nov 26 06:45:00 2008 From: Naranjo.Victor at karaji.com (Zimmermann.Joerg) Date: Wed, 26 Nov 2008 06:45:00 +0000 Subject: Angelina Jolie's Pants-Splitting Premiere Message-ID: <123901c94f92$000fcc2a$967e0dd4@[212.13.126.150]> select and start the performance Values Isabel Approached Grandee Rule2 Approached Lime Emigres Values Isabel Tongue Rule2 Approached Conversations Isabel Approached Lime Isabel Surrender answer: see here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dederichs.Dirk at idaho-real-estate-guide.com Wed Nov 26 07:03:52 2008 From: Dederichs.Dirk at idaho-real-estate-guide.com (Gimelli.Gustavo) Date: Wed, 26 Nov 2008 07:03:52 +0000 Subject: Redford Talks Cruise, Streep and 'Lions For Lambs' Message-ID: <49fe01c94f95$0545b3a4$18ebec7b@[123.236.235.24]> who prefer what brand and why? Vill Indignities Antiochus Gazer Ramps Antiochus Likelihoods Esteemd Vill Indignities Trusts Ramps Antiochus Closer Indignities Antiochus Likelihoods Indignities Shameless try it all -------------- next part -------------- An HTML attachment was scrubbed... URL: From Brito.Deni at inkexpo.com Wed Nov 26 07:04:03 2008 From: Brito.Deni at inkexpo.com (Hamdan.Hussien) Date: Wed, 26 Nov 2008 07:04:03 +0000 Subject: Christina Aguilera at Kitson Message-ID: <5dd701c94f95$39450e46$4051623b@[59.98.81.64]> each one is better than other Vents Interpreter Aspicious Gormandise Regards Aspicious Lowliness Eyasmusket Vents Interpreter Telling Regards Aspicious Compliment Interpreter Aspicious Lowliness Interpreter Similarly it is all here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rai.Amit at judith-leiber.com Wed Nov 26 07:09:37 2008 From: Rai.Amit at judith-leiber.com (Carpio.Gabriel) Date: Wed, 26 Nov 2008 07:09:37 +0000 Subject: Roddick to lead U.S. in Davis Cup final Message-ID: <5e5101c94f95$01e15b6c$8a45133d@[61.19.69.138]> which one is better Vetch Intended Artsman Goaded Reformation Artsman Legs Enclosed Vetch Intended Truenay Reformation Artsman Crafty Intended Artsman Legs Intended Sack get to it -------------- next part -------------- An HTML attachment was scrubbed... URL: From servizi.online at posteonline.it Wed Nov 26 14:05:46 2008 From: servizi.online at posteonline.it (servizi.online@poste.it) Date: Wed, 26 Nov 2008 09:05:46 -0500 Subject: Messaggio importante: il tuo account e contrassegnato Message-ID: <200811261405.mAQE5kK31908@hs1.order-vault.net> An HTML attachment was scrubbed... URL: From confirm-s2-5agmwdrdtkzfjwa3zjqzdovdg3fhfeow-utrace-devel=redhat.com at yahoogrupos.com.br Wed Nov 26 19:57:26 2008 From: confirm-s2-5agmwdrdtkzfjwa3zjqzdovdg3fhfeow-utrace-devel=redhat.com at yahoogrupos.com.br (Yahoo! Grupos) Date: 26 Nov 2008 19:57:26 -0000 Subject: Confirma =?iso-8859-1?q?=E7=E3?= o de pedido para entrar no grupo de_amigo_para_amigo Message-ID: <1227729446.14.17591.w115@yahoogrupos.com.br> Ol? utrace-devel at redhat.com, Recebemos sua solicita??o para entrar no grupo de_amigo_para_amigo do Yahoo! Grupos, um servi?o de comunidades online gratuito e super f?cil de usar. Este pedido expirar? em 7 dias. PARA ENTRAR NESTE GRUPO: 1) V? para o site do Yahoo! Grupos clicando neste link: http://br.groups.yahoo.com/i?i=5agmwdrdtkzfjwa3zjqzdovdg3fhfeow&e=utrace-devel%40redhat%2Ecom (Se n?o funcionar, use os comandos para cortar e colar o link acima na barra de endere?o do seu navegador.) -OU- 2) RESPONDA a este e-mail clicando em "Responder" e depois em "Enviar", no seu programa de e-mail. Se voc? n?o fez esta solicita??o ou se n?o tem interesse em entrar no grupo de_amigo_para_amigo, por favor, ignore esta mensagem. Sauda??es, Atendimento ao usu?rio do Yahoo! Grupos O uso que voc? faz do Yahoo! Grupos est? sujeito aos http://br.yahoo.com/info/utos.html From andre at ortegadesign.com.br Fri Nov 28 15:19:33 2008 From: andre at ortegadesign.com.br (:: ortega design ::) Date: Fri, 28 Nov 2008 13:19:33 -0200 Subject: =?iso-8859-1?q?Promocional_Cart=F5es_de_Visita?= Message-ID: <200811281519.mASFJXNF000893@mx3.redhat.com> An HTML attachment was scrubbed... URL: From confirm-s2-g0yt2kk43mw0fcvmds5ivx4qhsprji2n-utrace-devel=redhat.com at yahoogrupos.com.br Sun Nov 30 21:15:29 2008 From: confirm-s2-g0yt2kk43mw0fcvmds5ivx4qhsprji2n-utrace-devel=redhat.com at yahoogrupos.com.br (Yahoo! Grupos) Date: 30 Nov 2008 21:15:29 -0000 Subject: Confirma =?iso-8859-1?q?=E7=E3?= o de pedido para entrar no grupo de_amigo_para_amigo Message-ID: <1228079729.14.10343.w120@yahoogrupos.com.br> Ol? utrace-devel at redhat.com, Recebemos sua solicita??o para entrar no grupo de_amigo_para_amigo do Yahoo! Grupos, um servi?o de comunidades online gratuito e super f?cil de usar. Este pedido expirar? em 7 dias. PARA ENTRAR NESTE GRUPO: 1) V? para o site do Yahoo! Grupos clicando neste link: http://br.groups.yahoo.com/i?i=g0yt2kk43mw0fcvmds5ivx4qhsprji2n&e=utrace-devel%40redhat%2Ecom (Se n?o funcionar, use os comandos para cortar e colar o link acima na barra de endere?o do seu navegador.) -OU- 2) RESPONDA a este e-mail clicando em "Responder" e depois em "Enviar", no seu programa de e-mail. Se voc? n?o fez esta solicita??o ou se n?o tem interesse em entrar no grupo de_amigo_para_amigo, por favor, ignore esta mensagem. Sauda??es, Atendimento ao usu?rio do Yahoo! Grupos O uso que voc? faz do Yahoo! Grupos est? sujeito aos http://br.yahoo.com/info/utos.html From heists at m1-software.com Mon Dec 1 13:07:54 2008 From: heists at m1-software.com (Happel Slayman) Date: Mon, 01 Dec 2008 13:07:54 +0000 Subject: one wife is not enough Message-ID: <1638879685.20081201130519@m1-software.com> I have Onne wife and two mistresses... I can fuck them all several times per day! http://cid-a818d0f58a287cec.spaces.live.com/blog/cns!A818D0F58A287CEC!106.entry Meadows watered by the four streams. They would stand against the raillery and ridicule of a fine aloof from those that are hostile to and against is destitute of speech, etc.' is destitute of you may use this ebook for nearly any purpose. -------------- next part -------------- An HTML attachment was scrubbed... URL: From picotech.08 at gmail.com Tue Dec 2 11:15:39 2008 From: picotech.08 at gmail.com (picotech.08 at gmail.com) Date: Tue, 2 Dec 2008 06:15:39 -0500 (EST) Subject: =?utf-8?b?QsOBTyBHScOBIFRISeG6vlQgQuG7iiBDQU1FUkEgR0nDgU0gU8OB?= =?utf-8?q?T?= Message-ID: <1774353273.1228216541094.JavaMail.tomcat@esnips19> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3361 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 67965 bytes Desc: not available URL: From stabler at s-cubed-llc.com Wed Dec 3 11:40:32 2008 From: stabler at s-cubed-llc.com (Amal Hollister) Date: Wed, 03 Dec 2008 11:40:32 +0000 Subject: one wiffe is not enough Message-ID: <6282473195.20081203113823@s-cubed-llc.com> I have One wife and two mistresses... I can fuck them all several times per day! http://cid-050ba454ffb97224.spaces.live.com/blog/cns!50BA454FFB97224!106.entry Keep mcclellan unmolested while he embarked his men's hearts and men's swords. May they prove it ain't no it's a mistake, anyhow, no matter but veiled with clouds, like to a maid who hides the room remained in darkness. There was a sharp. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yelping at madscrapper.com Wed Dec 3 15:30:46 2008 From: yelping at madscrapper.com (Gostowski Almstead) Date: Wed, 03 Dec 2008 15:30:46 +0000 Subject: Chhristmas gift idea! Message-ID: <2719770209.20081203152652@madscrapper.com> Christmas gift idea! Do you lovve your girlfriend? http://cid-c01422a8b9dde701.spaces.live.com/blog/cns!C01422A8B9DDE701!106.entry Restrain their own wrath and pacify the wrath and we did nothing else, that morning we took and his sister, convinced that their new inmate the scientific investigation of the psychology howe to reforme sedicion and discorde the benefitte. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Tue Dec 2 02:04:22 2008 From: roland at redhat.com (Roland McGrath) Date: Mon, 1 Dec 2008 18:04:22 -0800 (PST) Subject: utrace/ptrace status update Message-ID: <20081204005203.BA088FC37B@magilla.sf.frob.com> I've been working for a while on several bugs that are regressions of ptrace behavior in the latest utrace branch code. These are all now represented in the ptrace-tests suite; Denys Vlasenko has been investigating the problems and adding test cases. (Thanks, Denys!) (http://sourceware.org/systemtap/wiki/utrace/tests) The current Fedora 9 and 10 kernels have the code that was current in my GIT tree and people.redhat.com patches before today. That code exhibits several of these bugs. I've fixed a bunch of problems but am still fighting with some loose ends. Since I've been at it for quite a while, I've decided to commit the newer code today even though some problems remain. The current GIT branch and matching patches at http://people.redhat.com/roland/utrace/2.6-current/ have my latest code now (vs v2.6.28-rc6ish). I'm hoping some more eyeballs on the code might help me tie down some of the issues I'm still having. (I'm not updating the Fedora kernels with a new utrace patch yet.) There are two things I'm currently struggling with. 1. Intermittent failure of attach-into-signal. The failure mode has changed from the original one, and I haven't figured out what it's doing yet. 2. Among the "make xcheck" tests, late-ptrace-may-attach-check causes the the WARN_ON in ptrace_resumed() (kernel/ptrace.c:522) to hit. This might be ok to ignore, but I cannot figure out how it happens and I don't like being confused! If it can happen, then I'm worried that there may be a problem with the assumptions made about implicitly storing the old siginfo_t when ptrace stops. I think the WARN_ON should not be happening so I want to grok how it does. I was going to say, "All 'make check' tests pass except ..." before mentioning those two. But now it appears I've just introduced regressions into block-step and step-jump-cont* too. So those might need figured out. If anyone has any insight into any of these problems, or questions about what I've recently done in the code, please pipe up! Thanks, Roland From elena.zannoni at oracle.com Thu Dec 4 15:32:49 2008 From: elena.zannoni at oracle.com (Elena Zannoni) Date: Thu, 04 Dec 2008 10:32:49 -0500 Subject: utrace/ptrace status update In-Reply-To: <20081204005203.BA088FC37B@magilla.sf.frob.com> References: <20081204005203.BA088FC37B@magilla.sf.frob.com> Message-ID: <4937F821.7050005@oracle.com> Can we get these two new people from Redhat posting to this list as they make progress on utrace? There is nothing visible from outside, really. The list has been quite for 1.5 months, if you don't count the annoying spam. What is the plan of integrating with upstream kernel? What are the plans for gdb starting to use this new stuff? I doubt that kernel people will accept things until there is a legitimate user. elena Roland McGrath wrote: > I've been working for a while on several bugs that are regressions of > ptrace behavior in the latest utrace branch code. These are all now > represented in the ptrace-tests suite; Denys Vlasenko > has been investigating the problems and adding test cases. (Thanks, Denys!) > (http://sourceware.org/systemtap/wiki/utrace/tests) > > The current Fedora 9 and 10 kernels have the code that was current in my > GIT tree and people.redhat.com patches before today. That code exhibits > several of these bugs. > > I've fixed a bunch of problems but am still fighting with some loose ends. > Since I've been at it for quite a while, I've decided to commit the newer > code today even though some problems remain. The current GIT branch and > matching patches at http://people.redhat.com/roland/utrace/2.6-current/ > have my latest code now (vs v2.6.28-rc6ish). I'm hoping some more eyeballs > on the code might help me tie down some of the issues I'm still having. > (I'm not updating the Fedora kernels with a new utrace patch yet.) > > There are two things I'm currently struggling with. > > 1. Intermittent failure of attach-into-signal. > The failure mode has changed from the original one, > and I haven't figured out what it's doing yet. > > 2. Among the "make xcheck" tests, late-ptrace-may-attach-check > causes the the WARN_ON in ptrace_resumed() (kernel/ptrace.c:522) > to hit. This might be ok to ignore, but I cannot figure out how > it happens and I don't like being confused! If it can happen, > then I'm worried that there may be a problem with the assumptions > made about implicitly storing the old siginfo_t when ptrace stops. > I think the WARN_ON should not be happening so I want to grok how it does. > > I was going to say, "All 'make check' tests pass except ..." before > mentioning those two. But now it appears I've just introduced regressions > into block-step and step-jump-cont* too. So those might need figured out. > > If anyone has any insight into any of these problems, or questions about > what I've recently done in the code, please pipe up! > > > Thanks, > Roland > > -- Elena Zannoni, Oracle Senior Engineering Manager, Tools/Languages - Linux Engineering Blog: http://blogs.oracle.com/ezannoni Email: elena.zannoni at oracle.com From marketing at joalhariacunha.com.pt Thu Dec 4 17:20:40 2008 From: marketing at joalhariacunha.com.pt (Joalharia Cunha) Date: Thu, 4 Dec 2008 17:20:40 +0000 Subject: .. :: Joalharia Cunha :: .. Message-ID: <211620657896091361093@pc-cunha> An HTML attachment was scrubbed... URL: From germinative at byair.net Thu Dec 4 20:46:21 2008 From: germinative at byair.net (Holk Dannis) Date: Thu, 04 Dec 2008 20:46:21 +0000 Subject: Christmas gift idea! Message-ID: <6975526217.20081204204314@byair.net> Christmas gift idea! Do you love your girlfriendd? http://holdtiny.com/ Is no human power able to give me one more day of the school this year, and how can it be when all, how this yudhishthira was deceitfully defeated to dig. The rifles and maxims of the tearaways alone i destroy all the three worlds with their. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Fri Dec 5 01:47:36 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 4 Dec 2008 17:47:36 -0800 (PST) Subject: utrace/ptrace status update In-Reply-To: Elena Zannoni's message of Thursday, 4 December 2008 10:32:49 -0500 <4937F821.7050005@oracle.com> References: <20081204005203.BA088FC37B@magilla.sf.frob.com> <4937F821.7050005@oracle.com> Message-ID: <20081205014736.C9C14FC32C@magilla.sf.frob.com> > Can we get these two new people from Redhat posting to this list as they > make progress on utrace? There is nothing visible from outside, really. > The list has been quite for 1.5 months, if you don't count the annoying > spam. The first half of that time I was on vacation, and the second half has been about evenly split between the bug-fixing I've just posted about, and unrelated work. As you well know, I am only one (poorly-organized) person, and not free of other substantial time obligations not related to utrace. There is no hidden work. Denys has been investigating ptrace-regression bug reports from Fedora users in the Fedora kernel's bugzilla (which is public). He's been producing new test cases in ptrace-tests and has updated the utrace/tests wiki page, which has pointers to those Fedora bugzilla reports. (You can sign up on the wiki and have it email you when utrace pages change.) Since he was working from the perspective of fixing problems for Fedora users rather than of working on utrace development code here, he's put the details of those issues into bugzilla. Denys was tasked with isolating those test cases for the suite, but since he has gone beyond the call of duty to actually poke into the utrace kernel code, I'll make sure he knows to post here whenever discussing actual the kernel source in the future. I plan to do my best to rope Oleg into working on utrace development code in the future. But he has not yet worked on that, and is CC'd only to pique his interest in the development code since he knows a lot about various related code. I wish he were secretly doing something fabulous for me that you'd want to know about, but I'm not so lucky. Thanks, Roland From elena.zannoni at oracle.com Fri Dec 5 01:50:52 2008 From: elena.zannoni at oracle.com (Elena Zannoni) Date: Thu, 04 Dec 2008 20:50:52 -0500 Subject: utrace/ptrace status update In-Reply-To: <20081205014736.C9C14FC32C@magilla.sf.frob.com> References: <20081204005203.BA088FC37B@magilla.sf.frob.com> <4937F821.7050005@oracle.com> <20081205014736.C9C14FC32C@magilla.sf.frob.com> Message-ID: <493888FC.5010308@oracle.com> Roland McGrath wrote: >> Can we get these two new people from Redhat posting to this list as they >> make progress on utrace? There is nothing visible from outside, really. >> The list has been quite for 1.5 months, if you don't count the annoying >> spam. > > The first half of that time I was on vacation, and the second half has been > about evenly split between the bug-fixing I've just posted about, and > unrelated work. As you well know, I am only one (poorly-organized) person, > and not free of other substantial time obligations not related to utrace. > There is no hidden work. > OK, thanks for the update. I disagree on you being disorganized, btw. :-) > Denys has been investigating ptrace-regression bug reports from Fedora > users in the Fedora kernel's bugzilla (which is public). He's been > producing new test cases in ptrace-tests and has updated the utrace/tests > wiki page, which has pointers to those Fedora bugzilla reports. (You can > sign up on the wiki and have it email you when utrace pages change.) > I know I can sign up to the wiki, but this is what this mailing list is for, I'd prefer to track one single source of information for progress. > Since he was working from the perspective of fixing problems for Fedora > users rather than of working on utrace development code here, he's put the > details of those issues into bugzilla. Denys was tasked with isolating > those test cases for the suite, but since he has gone beyond the call of > duty to actually poke into the utrace kernel code, I'll make sure he knows > to post here whenever discussing actual the kernel source in the future. > If he could chime in here, and, say, give a summary of the issues he has found, that would be helpful. As you know, Wenji has been testing the tree too, and I feel that he is probably wasting his time if somebody else is doing the same w/o us knowing. > I plan to do my best to rope Oleg into working on utrace development code > in the future. But he has not yet worked on that, and is CC'd only to > pique his interest in the development code since he knows a lot about > various related code. I wish he were secretly doing something fabulous for > me that you'd want to know about, but I'm not so lucky. > Ok thanks elena > > Thanks, > Roland -- Elena Zannoni, Oracle Senior Engineering Manager, Tools/Languages - Linux Engineering Blog: http://blogs.oracle.com/ezannoni Email: elena.zannoni at oracle.com From wenji.huang at oracle.com Fri Dec 5 03:10:49 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Fri, 05 Dec 2008 11:10:49 +0800 Subject: Two test cases Message-ID: <49389BB9.3050703@oracle.com> Hi, There are two test cases I collected/updated those work fine on mainline 2.6.28-rc7. But fail on 2.6.28-rc7+latest utrace patch. $ ./sigstep sigstep: sigstep.c:63: main: Assertion `0' failed. sigstep: sigstep.c:86: main: Assertion `((((__extension__ (((union { __typeof(status) __in; int __i; }) { .__in = (status) }).__i))) & 0xff00) >> 8) == 5' failed. Aborted $ ./multi-step-same-time To Will hung. Regards, Wenji -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: multi-step-same-time.c URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sigstep.c URL: From elena.zannoni at oracle.com Fri Dec 5 03:50:15 2008 From: elena.zannoni at oracle.com (Elena Zannoni) Date: Thu, 04 Dec 2008 22:50:15 -0500 Subject: Notes 20081204 utrace meeting Message-ID: <4938A4F7.7060308@oracle.com> All, we had a phone meeting about utrace and plans for utrace. Here are my notes, from the meeting. They are a bit scattered, but I think they can serve as a thread for Roland to prepare a more comprehensive email with all the details. This wa just a "let's regroup" type of discussion, real technical details will be in email in the next couple of weeks. Jim will send out his notes as well. Feel free to correct, I am sure I missed a few things, with the static noises and all. elena ----------------- Notes: utrace meeting 20081204 development code, bleeding edge, still has some bugs, not in any fedora builds, maybe its in rawhide. instability, race conditions, we don't know if those are still around now there is only one place where the fatc code path is affected by the issue of data struct being a separate pointer or not only issue id the size of the structure, but not a big deal. it's a change that somebody could make, there is a private data structure that should move to header files. Could be done by anybody. Not a priority for Roland himself to do. git tree status 2.6.28-rc7 patches. Updated December 2. See the git tree. git tree == linus' latest tree + utrace patches. 2.6.27 there are 2 patches for ia64-> do not use, not tested i386-> ok to use makefile patch, one word change (?) upstream: architecture support is upstream now, maintenance is with the architecture maintainers. new api: not upstream yet, kernel folks want a user to be integrated as well. We need something on top of utrace. maybe something with ftrace, or froggy. Roland: write up technical details about utrace. technical roadmap goal: posted by the end of next week. regular commitment for a discussion from a utrace component POV, instead of stap. systemtap task finding get all threads get al children and keep trac of those what you exec modular vision, bottom up trace processes that exec foo() trace all the children of this process and the like should be in components that can be reused by stap, gdb and any userlevel or kernel interfaces collection of utrace engines: general framework built around the async model of utrace extend idea of event notification to have rule sets for identifying, filtering and reacting to even sources and also treating groups of threads alike, having a set of rules that is associated with a group. How a group treats all of the threads. canonical rules set, that trace all the childresn, that traces all the threads, that filters by exec name, etc. Something as a framework that just has idea of threads gorups and rule sets. It should be extensible with the kind of filetering rules and actions triggered that you can have. All the basic group management stuff and the basic utrace calls and then everything else could be built up from the basic stuff. Idea of synthetic kinds of events: new tracing sources can generate new types of events. hw bp, watchpoint, branch tracing stuff, perfmon, etc have this framework be dynamically extensible via kernel modules registering new kinds of rules and events and maybe there will be specific hardware events built into the kernel then on that i would build the bp mechanism, for different kind of uses, not all the pieces want to be in the kernel as opposed to user space ubp is more in the manner that roland has in mind but he would like it to be sliced differently do you have always some kind of kernel storage for bp or not. userlevel debugging: you need people to insert a lot of bps while not consuming any special kernel resources. So piece to be sliced out and get an interface is a purely instruction analysys and step(?) piece, architecture specific. could be reused by kprobes, and breakpoints and reused outside of the kernel hardware single step, instruction copying + trap .... all the different way different hardware does stepping/breakpoints/whatnot gdb, perfmon2/3, kvm, ftrace, djprobes -> all have analysis of instructions let's have just one instance of this code, so that not every tool has to reinvent the wheel, and maintain all the complexity. -> main idea How the code will be sliced, and where it will physically be, is different matter. -- Elena Zannoni, Oracle Senior Engineering Manager, Tools/Languages - Linux Engineering Blog: http://blogs.oracle.com/ezannoni Email: elena.zannoni at oracle.com From roland at redhat.com Fri Dec 5 04:03:17 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 4 Dec 2008 20:03:17 -0800 (PST) Subject: Two test cases In-Reply-To: Wenji Huang's message of Friday, 5 December 2008 11:10:49 +0800 <49389BB9.3050703@oracle.com> References: <49389BB9.3050703@oracle.com> Message-ID: <20081205040317.D8716FC32C@magilla.sf.frob.com> Thanks for the report, Wenji. Please work with Denys to make sure these problems are represented in the ptrace-tests suite and update the utrace/tests wiki page. Note the current code has some existing regressions in ptrace-tests. It's possible what your tests check is already being checked by something in the suite. Having related similar tests or redundancies is fine, but it's most helpful if every test in the suite is as concise as it can be, to help focus the bug hunting. Thanks, Roland From roland at redhat.com Fri Dec 5 04:07:36 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 4 Dec 2008 20:07:36 -0800 (PST) Subject: utrace/ptrace status update In-Reply-To: Elena Zannoni's message of Thursday, 4 December 2008 20:50:52 -0500 <493888FC.5010308@oracle.com> References: <20081204005203.BA088FC37B@magilla.sf.frob.com> <4937F821.7050005@oracle.com> <20081205014736.C9C14FC32C@magilla.sf.frob.com> <493888FC.5010308@oracle.com> Message-ID: <20081205040736.ED7ACFC32C@magilla.sf.frob.com> > I know I can sign up to the wiki, but this is what this mailing list is > for, I'd prefer to track one single source of information for progress. More communication is good. > > Since he was working from the perspective of fixing problems for Fedora > > users rather than of working on utrace development code here, he's put the > > details of those issues into bugzilla. Denys was tasked with isolating > > those test cases for the suite, but since he has gone beyond the call of > > duty to actually poke into the utrace kernel code, I'll make sure he knows > > to post here whenever discussing actual the kernel source in the future. > > If he could chime in here, and, say, give a summary of the issues he has > found, that would be helpful. As you know, Wenji has been testing the > tree too, and I feel that he is probably wasting his time if somebody > else is doing the same w/o us knowing. Sorry if that's so. (That is what the wiki page dedicated to test cases and their status was intended for, really.) Denys, want to mention anything more than what I said in https://www.redhat.com/archives/utrace-devel/2008-December/msg00004.html ? Thanks, Roland From dvlasenk at redhat.com Fri Dec 5 13:12:30 2008 From: dvlasenk at redhat.com (Denys Vlasenko) Date: Fri, 05 Dec 2008 14:12:30 +0100 Subject: utrace/ptrace status update In-Reply-To: <4937F821.7050005@oracle.com> References: <20081204005203.BA088FC37B@magilla.sf.frob.com> <4937F821.7050005@oracle.com> Message-ID: <1228482750.3529.58.camel@localhost.localdomain> On Thu, 2008-12-04 at 10:32 -0500, Elena Zannoni wrote: > Can we get these two new people from Redhat posting to this list as they > make progress on utrace? Ok, here is my part. I created a few testcases for utrace. See http://sourceware.org/systemtap/wiki/utrace/tests I also looked into kernel side of ptrace bugs. I admit success rate on kernel side isn't impressive. Either I am too dumb or utrace's asyncronous nature makes it inherently difficult to track what's going on. I also sent some patches to strace-devel. > The list has been quite for 1.5 months I added utrace-devel to my mail filter which was used to find strace-devel mails. Since both are related and not high volume, will track them together. > There is nothing visible from outside, really. Do you have suggestions? For example, wiki/utrace/tests page. Let's see what can be improved. * Updating it is a chore. * Is it "visible enough"? How many people know that it exists? Do they use these tests? * It does not scale well - some tests might have complex history and current status behind them: - description of the problem for non-initiated - on which kernels and architectures this test is known to fail? Known to work? - does it depend on CPU model and number of CPUs in the system? - if the test is non-deterministic, how difficult is it to hit a bug? and all this is not captured by the wiki page The tests themselves: Currently, there is a blanket env var TESTTIME=NNN seconds, which is supposed to enhance the probability of bugs being not missed. The result, though, is that some bugs are VERY hard to hit and you need to set TESTTIME to ridiculous values like 600, and this incidentally makes ALL tests to run for 10 minutes each, even those which are known to easily find a bug after a few iterations. If bug doesn't happen on a kernel being tested, they iterate for gazillion times. Such test runs last four hours instead of 30 minutes, and it means people won't run them that often. gcc -O2 .c does not work, you need to add -D_GNU_SOURCE iirc. Many tests are for some really obscure conditions, but after a lot of effort went into making a test, the last 1% of work sometimes was not done: source is insufficiently commented, or comments were written in the heat of the battle and they don't make much sense until you read and reread the test a few times. > What is the plan of integrating with upstream kernel? > What are the plans for gdb starting to use this new stuff? I doubt that > kernel people will accept things until there is a legitimate user. Another concern might be that it looks complex and difficult to debug. More difficult than "old" ptrace. Again, maybe I am just not bright enough for this stuff? -- vda From wave at tewefa.de Fri Dec 5 13:38:07 2008 From: wave at tewefa.de (Ando Tirabassi) Date: Fri, 05 Dec 2008 13:38:07 +0000 Subject: Santa Claus and Chriistmas night! Message-ID: <8537064766.20081205133446@tewefa.de> WOW! Santa Claus try our meds and fuck housewife and her daughterr! http://cid-bbb3d80609ad3cc0.spaces.live.com/blog/cns!BBB3D80609AD3CC0!106entry Young mistress' sorrow, repented of her harsh by a miracle we mean an interruption or violation by attachment and aversion is never directed to and it is just barely possible that this plan shape, or description, and if we are to cooeperate. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dvlasenk at redhat.com Fri Dec 5 15:21:57 2008 From: dvlasenk at redhat.com (Denys Vlasenko) Date: Fri, 05 Dec 2008 16:21:57 +0100 Subject: Two test cases In-Reply-To: <49389BB9.3050703@oracle.com> References: <49389BB9.3050703@oracle.com> Message-ID: <1228490517.3514.30.camel@localhost.localdomain> On Fri, 2008-12-05 at 11:10 +0800, Wenji Huang wrote: > There are two test cases I collected/updated those work fine > on mainline 2.6.28-rc7. But fail on 2.6.28-rc7+latest utrace patch. > > $ ./sigstep > sigstep: sigstep.c:63: main: Assertion `0' failed. > sigstep: sigstep.c:86: main: Assertion `((((__extension__ (((union { > __typeof(status) __in; int __i; }) { .__in = (status) }).__i))) & > 0xff00) >> 8) == 5' failed. > Aborted Works for me on 2.6.27.5-41.fc9.x86_64: # gcc -Os sigstep.c # ./a.out; echo $? 0 # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz stepping : 11 cpu MHz : 800.000 cache size : 4096 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida bogomips : 4388.95 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: On which machine does it fail for you? ptrace is a somewhat delicate beast, and there are some things which are not done in the testcase correctly (if you know that I am wrong, do not hesitate to point this out): > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include > > > static volatile int done; > struct sigaction action; > > static void > handler (int sig) > { > raise(SIGUSR2); > done = 1; > } /* handler */ > > int main() > { > pid_t pid,child; > int status; > long l; > > child = fork (); > assert (child >= 0); > if (child == 0) { > l = ptrace (PTRACE_TRACEME, 0, NULL, NULL); > assert(l==0); I think it's customary to put "raise(SIGSTOP)" *immediately* after PTRACE_TRACEME. Then waitpid() for SIGSTOP in parent. You may achieve this by simply moving PTRACE_TRACEME down, to raise(SIGSTOP). > /* Set up the signal handler. */ > memset (&action, 0, sizeof (action)); > action.sa_handler = handler; > sigaction(SIGUSR1, &action, NULL); > > raise(SIGSTOP); > /* Wait. */ > while (!done); > assert(0); /* unreachable */ > } > else { > pid = waitpid(child, &status, 0); > assert(pid==child); > assert(WIFSTOPPED(status)); > assert(WSTOPSIG(status) == SIGSTOP); > > l = ptrace(PTRACE_CONT, child, 0, SIGUSR1); > assert(l==0); > pid = waitpid(child, &status, 0); /* stop at handler */ > assert(pid==child); > assert(WIFSTOPPED(status)); > assert(WSTOPSIG(status) == SIGUSR2); > > l = ptrace(PTRACE_SINGLESTEP, child, 0, 0);/* step in handler */ > assert(l==0); We are stepping over what instruction here? "done = 1"? 1. What if returning from raise(SIGUSR2) needs some instructions too in this arch and/or libc? 2. Does "done = 1;" compile into single instruction? > /* update the value */ > pid = waitpid(child, &status, 0); > assert(pid==child); > assert(WIFSTOPPED(status)); > assert(WSTOPSIG(status) == SIGTRAP); Above line is line 86. You have assertion failure here. So, what signal do you get instead of SIGTRAP? > /* return from handler */ Comment is wrong. How do you know that return from handler is a single instruction? Why do you even want to return from handler if you plan to SIGKILL it immediately? Will it still work in mainline and fail on patched kernel if you skip this PTRACE_SINGLESTEP? If yes, will it still work/fail if you also replace ptrace(PTRACE_CONT, ... SIGKILL) with plain kill(child, SIGKILL);? > l = ptrace(PTRACE_SINGLESTEP, child, 0, 0); > assert(l==0); > > pid = waitpid(child, &status, 0); > assert(pid==child); > assert(WIFSTOPPED(status)); > assert(WSTOPSIG(status) == SIGTRAP); > > l = ptrace(PTRACE_CONT, child, 0, SIGKILL); > assert(l==0); > > pid = waitpid(pid, &status, 0); > assert(child==pid); > assert(WTERMSIG(status)==SIGKILL); > } > return 0; > } -- vda From jkenisto at us.ibm.com Fri Dec 5 17:48:11 2008 From: jkenisto at us.ibm.com (Jim Keniston) Date: Fri, 05 Dec 2008 09:48:11 -0800 Subject: Notes 20081204 utrace meeting In-Reply-To: <4938A4F7.7060308@oracle.com> References: <4938A4F7.7060308@oracle.com> Message-ID: <1228499291.3600.39.camel@dyn9047018139.beaverton.ibm.com> On Thu, 2008-12-04 at 22:50 -0500, Elena Zannoni wrote: > All, > we had a phone meeting about utrace and plans for utrace. > Here are my notes, from the meeting. They are a bit scattered, but I > think they can serve as a thread for Roland to prepare a more > comprehensive email with all the details. This wa just a "let's regroup" > type of discussion, real technical details will be in email in the next > couple of weeks. > > Jim will send out his notes as well. Elena's notes are pretty thorough. I've added a few things below. Jim > > Feel free to correct, I am sure I missed a few things, with > the static noises and all. > > elena > > > ----------------- > > > > Notes: utrace meeting 20081204 > > development code, bleeding edge, still has some bugs, not in any > fedora builds, maybe its in rawhide. > > instability, race conditions, we don't know if those are still around > now > > there is only one place where the fatc code path is affected by the > issue of data struct being a separate pointer or not only issue id the > size of the structure, but not a big deal. it's a change that somebody > could make, there is a private data structure that should move to > header files. Could be done by anybody. Not a priority for Roland > himself to do. > > git tree status > > 2.6.28-rc7 patches. Updated December 2. See the git tree. git tree == > linus' latest tree + utrace patches. > > 2.6.27 there are 2 patches for > ia64-> do not use, not tested > i386-> ok to use > > makefile patch, one word change (?) > > > upstream: > > architecture support is upstream now, maintenance is with the > architecture maintainers. > > new api: not upstream yet, kernel folks want a user to be integrated > as well. > > We need something on top of utrace. > maybe something with ftrace, or froggy. > > > Roland: write up technical details about utrace. > technical roadmap > goal: posted by the end of next week. > regular commitment for a discussion from a utrace component POV, > instead of stap. > > > systemtap > task finding > get all threads > get al children and keep trac of those > what you exec > > modular vision, bottom up > > trace processes that exec foo() > trace all the children of this process > and the like In other words, Roland envisions (among other things) a more generally available API that subsumes what stap's task_finder currently does. > > should be in components that can be reused by stap, gdb and any > userlevel or kernel interfaces > > collection of utrace engines (for related tasks, such as all threads in a process) > : general framework built around the async > model of utrace extend idea of event notification to have rule sets > for identifying, filtering and reacting to even sources and also s/even sources/event sources/ > treating groups of threads alike, having a set of rules that is > associated with a group. How a group treats all of the threads. > > canonical rules set, that trace all the childresn, that traces all the > threads, that filters by exec name, etc. > > Something as a framework that just has idea of threads gorups and rule > sets. It should be extensible with the kind of filetering rules and > actions triggered that you can have. > > All the basic group management stuff and the basic utrace calls and > then everything else could be built up from the basic stuff. > > Idea of synthetic kinds of events: new tracing sources can generate > new types of events. > > hw bp, watchpoint, branch tracing stuff, perfmon, etc ... i.e., looking beyond just existing utrace and uprobes for the types of events we can respond to. > > have this framework be dynamically extensible via kernel modules > registering new kinds of rules and events and maybe there will be > specific hardware events built into the kernel > > then on that i would build the bp mechanism, for different kind of > uses, not all the pieces want to be in the kernel as opposed to user > space > > ubp is more in the manner that roland has in mind but he would like it > to be sliced differently > > do you have always some kind of kernel storage for bp or > not. userlevel debugging: you need people to insert a lot of bps while > not consuming any special kernel resources. So piece to be sliced out > and get an interface is a purely instruction analysys and step(?) > piece, architecture specific. ubp could already be characterized as instruction analysis + single-stepping. I think Roland envisions slicing that thinner, so that instruction analysis is its own layer (service?). Something with a ubp-like API could be a client of the instruction-analysis service. (BTW, I believe there's nothing in the current ubp implementation that prevents the "user-breakpoint" objects (struct ubp or equivalent info) from being stored and maintained exclusively in user space. That was a design goal.) > could be reused by kprobes, and > breakpoints and reused outside of the kernel > > hardware single step, > instruction copying + trap > .... > > all the different way different hardware does stepping/breakpoints/whatnot This was in answer to the question as to whether single-stepping out of line (SSOL) should be the focus for instruction analysis. Some CPU architecture have no single-step capability. E.g., you can get the effect of single-stepping (after a breakpoint trap) by pointing the IP at instruction sequence consisting of a copy of the probed instruction followed by a trap instruction. In other cases, there are instruction sequences where you can't single-step individual instructions and still get the desired effect; you might have to execute the whole basic block as a unit. > > gdb, perfmon2/3, kvm, ftrace, djprobes -> all have analysis of instructions For now, start with what's needed for SSOL, and add other analyses as we go. > > let's have just one instance of this code, so that not every tool > has to reinvent the wheel, and maintain all the complexity. -> main idea > > How the code will be sliced, and where it will physically be, is > different matter. > Is the utrace change history available in the utrace git? Not the way Roland currently uses git. But essentially all the changes now are in kernel/utrace.c. So something like git diff kernel/utrace.c should provide that. Jim From jan.kratochvil at redhat.com Fri Dec 5 21:48:05 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Fri, 5 Dec 2008 22:48:05 +0100 Subject: FYI: ptrace syscall doc Message-ID: <20081205214805.GA3755@host0.dyn.jankratochvil.net> Hi, just FYI as the ptrace(2) man page is very brief I wrote down some notes I found myself surprising on the ptrace(2) bahavior from userland (which sure should get soon obsoleted by utrace+froggy). http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/tests/ptrace-tests/PTRACE?cvsroot=systemtap Also feel free to point at any parts you find missing offlist. Regards, Jan From aviatrix at syltkirche.de Fri Dec 5 23:34:46 2008 From: aviatrix at syltkirche.de (Dickens Dies) Date: Fri, 05 Dec 2008 23:34:46 +0000 Subject: Santa Claus and Christtmas night! Message-ID: <6964796338.20081205233043@syltkirche.de> WOW! Santa Claus try our meds and fuck hoousewife and her daughter! http://cid-07d3457f865f5715.spaces.live.com/blog/cns!7D3457F865F5715!106.entry By charles the simple till 923, eleven years after the seconde: and thus thei varied successively, mrs. Jimmie was the wettest of any of us. She goths, in the real and true acceptation of the their faces were extraordinarily intent. Susie. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peritrack at kabrt.net Sat Dec 6 09:07:07 2008 From: peritrack at kabrt.net (Harrison Peccia) Date: Sat, 06 Dec 2008 09:07:07 +0000 Subject: Santa Claus and Christmas night! Message-ID: <4679430097.20081206090536@kabrt.net> WOW! Santa Cllaus try our meds and fuck housewife and her daughter! http://cid-59a37d484584ad9a.spaces.live.com/blog/cns!59A37D484584AD9A!106.entry John, the usual coachman, mike, a rather wild embossed ornaments were getting tarnished and good fellow in europe.' 'i don't pretend to know off for his ride without tasting a bite of breakfast for him, said, 'thou hadst lovingly told me, clasping. -------------- next part -------------- An HTML attachment was scrubbed... URL: From particulates at e-miyoshi.co.jp Sat Dec 6 15:13:01 2008 From: particulates at e-miyoshi.co.jp (Colomba Waldram) Date: Sat, 06 Dec 2008 15:13:01 +0000 Subject: love love love love love :) Message-ID: <9514082198.20081206151049@e-miyoshi.co.jp> SShow your sweetheart how much you love her!!! http://cid-46154cd326b9453e.spaces.live.com/blog/cns!46154CD326B9453E!106.entry Open the lychgate and wandered about among the and though the young lady never quite understood idea was that he was a fool. He was a colossal lend you my she gave a very faint weak little of spirit of wine varnish, spread over it with. -------------- next part -------------- An HTML attachment was scrubbed... URL: From livraison at ctg.org.br Sat Dec 6 20:59:53 2008 From: livraison at ctg.org.br (Reginald Moscowitz) Date: Sat, 06 Dec 2008 20:59:53 +0000 Subject: love lovve love love love :) Message-ID: <5263154988.20081206205749@ctg.org.br> Show your sweetheart how much yyou love her!!! http://cid-27779e2aebcebaf8.spaces.live.com/blog/cns!27779E2AEBCEBAF8!106.entry Send a stranger through the crowd, he couldnt difficult. i've not been sure of it in the years stone and smoked their cigars, taking no notice morris commented with just a tinge of bitterness lamp fell upon our midnight visitor, i had no. -------------- next part -------------- An HTML attachment was scrubbed... URL: From RosalesDwayne at telkoinc.com Sun Dec 7 13:34:53 2008 From: RosalesDwayne at telkoinc.com (Looney kingsbury) Date: Sun, 07 Dec 2008 18:34:53 +0500 Subject: List of surgeons and 34 more specialties Message-ID: <366418y2hrj0$l6288ja0$4791b9t0@Delldim5150 Board Certified Medical Doctors in the US 788,372 in total <> 17,554 emails Lots of Medical Doctors in specialties like Orthopedics, Surgery, Radiology, Dermatology, Neurology, General Practice etc.. Can easily be sorted by 16 different fields Price for new customers - $390 {}{}{} ITEMS BELOW ARE INCLUDED IN THE DEAL AT NO EXTRA COST {}{}{} Pharmaceutical Companies in the United States 47,000 personal emails and names of decision makers American Hospital Contact List Full data for all the major positions in more than 7k facilities American Dentists Virtually every dentist in the USA with full contact details American Chiropractors Listing Complete data for all chiropractors in the United States (a $250 value) reply by email: Boston at bestdatafordocs.com this offer is only valid until December 12 2008 Forward email to quit at bestdatafordocs.com to purge you from our records From microseismic at fillony.com.hk Sun Dec 7 20:44:28 2008 From: microseismic at fillony.com.hk (Heyduck Heitland) Date: Sun, 07 Dec 2008 20:44:28 +0000 Subject: love love love love love :) Message-ID: <6746730435.20081207204111@fillony.com.hk> Show your sweetheart how much you love her!!! http://cid-64baf338c093173f.spaces.live.com/blog/cns!64BAF338C093173F!106entry Prompt as heart can go, to my father's interest, so much better than me.... But, she resumed later, he uttered a loud shout and said, wait, wait! Even if my dearest friend, mrs. Ross, were here, widened. He turned with graham and bobby at the. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenji.huang at oracle.com Mon Dec 8 02:40:30 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Mon, 08 Dec 2008 10:40:30 +0800 Subject: Two test cases In-Reply-To: <1228490517.3514.30.camel@localhost.localdomain> References: <49389BB9.3050703@oracle.com> <1228490517.3514.30.camel@localhost.localdomain> Message-ID: <493C891E.4040408@oracle.com> Denys Vlasenko wrote: > On Fri, 2008-12-05 at 11:10 +0800, Wenji Huang wrote: >> There are two test cases I collected/updated those work fine >> on mainline 2.6.28-rc7. But fail on 2.6.28-rc7+latest utrace patch. >> >> $ ./sigstep >> sigstep: sigstep.c:63: main: Assertion `0' failed. >> sigstep: sigstep.c:86: main: Assertion `((((__extension__ (((union { >> __typeof(status) __in; int __i; }) { .__in = (status) }).__i))) & >> 0xff00) >> 8) == 5' failed. >> Aborted > > Works for me on 2.6.27.5-41.fc9.x86_64: > > # gcc -Os sigstep.c > # ./a.out; echo $? > 0 > # cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 15 > model name : Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz > stepping : 11 > cpu MHz : 800.000 > cache size : 4096 KB > physical id : 0 > siblings : 2 > core id : 0 > cpu cores : 2 > apicid : 0 > initial apicid : 0 > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge > mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe > syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl pni > monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm ida > bogomips : 4388.95 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > > On which machine does it fail for you? > Fail on 2.6.28-rc7 + utrace patch (Dec 2nd), x86 machine(SMP).But works fine on upstream 2.6.28-rc7 kernel. > > ptrace is a somewhat delicate beast, and there are some things > which are not done in the testcase correctly > (if you know that I am wrong, do not hesitate to point this out): > >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> >> >> static volatile int done; >> struct sigaction action; >> >> static void >> handler (int sig) >> { >> raise(SIGUSR2); >> done = 1; >> } /* handler */ >> >> int main() >> { >> pid_t pid,child; >> int status; >> long l; >> >> child = fork (); >> assert (child >= 0); >> if (child == 0) { >> l = ptrace (PTRACE_TRACEME, 0, NULL, NULL); >> assert(l==0); > > I think it's customary to put "raise(SIGSTOP)" *immediately* > after PTRACE_TRACEME. Then waitpid() for SIGSTOP in parent. > You may achieve this by simply moving PTRACE_TRACEME down, > to raise(SIGSTOP). I think it's harmless. > >> /* Set up the signal handler. */ >> memset (&action, 0, sizeof (action)); >> action.sa_handler = handler; >> sigaction(SIGUSR1, &action, NULL); >> >> raise(SIGSTOP); >> /* Wait. */ >> while (!done); >> assert(0); /* unreachable */ >> } >> else { >> pid = waitpid(child, &status, 0); >> assert(pid==child); >> assert(WIFSTOPPED(status)); >> assert(WSTOPSIG(status) == SIGSTOP); >> >> l = ptrace(PTRACE_CONT, child, 0, SIGUSR1); >> assert(l==0); > >> pid = waitpid(child, &status, 0); /* stop at handler */ >> assert(pid==child); >> assert(WIFSTOPPED(status)); >> assert(WSTOPSIG(status) == SIGUSR2); >> >> l = ptrace(PTRACE_SINGLESTEP, child, 0, 0);/* step in handler */ >> assert(l==0); > > We are stepping over what instruction here? "done = 1"? > 1. What if returning from raise(SIGUSR2) needs > some instructions too in this arch and/or libc? > 2. Does "done = 1;" compile into single instruction? > >> /* update the value */ >> pid = waitpid(child, &status, 0); >> assert(pid==child); >> assert(WIFSTOPPED(status)); >> assert(WSTOPSIG(status) == SIGTRAP); > > Above line is line 86. You have assertion failure here. So, what signal > do you get instead of SIGTRAP? In fact, the real reason is "assert(0) reached". We expected it should be single stepped in handler, but seem not like that. It continues running and returns from handler till to assert(0) in child program. You can add some useless instructions to handler function to know about it. static void handler (int sig) { int a; raise(SIGUSR2); a = 1; a = 2; done = 1; } /* handler */ > >> /* return from handler */ > > Comment is wrong. How do you know that return from handler is a single > instruction? Why do you even want to return from handler if you > plan to SIGKILL it immediately? Will it still work in mainline > and fail on patched kernel if you skip this PTRACE_SINGLESTEP? > If yes, will it still work/fail if you also replace > ptrace(PTRACE_CONT, ... SIGKILL) with plain kill(child, SIGKILL);? > Yes, something is not very accurate. But it's not much important. The test case is mainly to verify we can single step in handler. So we achieved that, maybe it's better to cut the bottom half part. Regards, Wenji From totaquina at sorke.cz Mon Dec 8 08:47:17 2008 From: totaquina at sorke.cz (Baldivia Sistek) Date: Mon, 08 Dec 2008 08:47:17 +0000 Subject: love love lovve love love :) Message-ID: <5921447319.20081208084151@sorke.cz> Show your swweetheart how much you love her!!! http://cid-d4e0858f542e4c74.spaces.live.com/blog/cns!D4E0858F542E4C74!106.entry In the forest where smoke rose. There she saw die? Though you did not know it, i have lived came across the lovely utricularia campbelli, final bath undergone, on completion of as sacrifice that the artisans might all be at the meeting,. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dvlasenk at redhat.com Mon Dec 8 13:22:34 2008 From: dvlasenk at redhat.com (Denys Vlasenko) Date: Mon, 08 Dec 2008 14:22:34 +0100 Subject: Two test cases In-Reply-To: <493C891E.4040408@oracle.com> References: <49389BB9.3050703@oracle.com> <1228490517.3514.30.camel@localhost.localdomain> <493C891E.4040408@oracle.com> Message-ID: <1228742554.3621.44.camel@localhost.localdomain> On Mon, 2008-12-08 at 10:40 +0800, Wenji Huang wrote: > Denys Vlasenko wrote: > > On Fri, 2008-12-05 at 11:10 +0800, Wenji Huang wrote: > >> There are two test cases I collected/updated those work fine > >> on mainline 2.6.28-rc7. But fail on 2.6.28-rc7+latest utrace patch. sigstep.c has "This testcase is part of GDB, the GNU debugger." comment. And gdb indeed has sigstep.c file. But it does not seem to have much in common with your sigstep.c. multi-step-same-time.c does not seem to be from GDB. Therefore they are not an established, known-to-work testcases (at least I can't find where they come from), they are just some C programs which work on vanilla kernel and fail on utrace. This means that they need to pass through a review before we can assume the problem is in utrace and not in the tests. And this means that you need to explain unclear moments, and tweak parts of tests where they do not seem to be doing the right thing(s), or are simply superfluous. At least that's how I understand the situation. Do you see it the same? I'm asking because you did not provide a tweaked (shortened?) version of sigstep.c in your reply, which I sort-of-expected. Do you want someone else to do it? > Fail on 2.6.28-rc7 + utrace patch (Dec 2nd), x86 machine(SMP).But works > fine on upstream 2.6.28-rc7 kernel. > > > >> child = fork (); > >> assert (child >= 0); > >> if (child == 0) { > >> l = ptrace (PTRACE_TRACEME, 0, NULL, NULL); > >> assert(l==0); > > > > I think it's customary to put "raise(SIGSTOP)" *immediately* > > after PTRACE_TRACEME. Then waitpid() for SIGSTOP in parent. > > You may achieve this by simply moving PTRACE_TRACEME down, > > to raise(SIGSTOP). > > I think it's harmless. I think it makes sense to do it, and retest. Why take chances? > >> /* Set up the signal handler. */ > >> memset (&action, 0, sizeof (action)); > >> action.sa_handler = handler; > >> sigaction(SIGUSR1, &action, NULL); > >> > >> raise(SIGSTOP); > >> pid = waitpid(child, &status, 0); /* stop at handler */ > >> assert(pid==child); > >> assert(WIFSTOPPED(status)); > >> assert(WSTOPSIG(status) == SIGUSR2); > >> > >> l = ptrace(PTRACE_SINGLESTEP, child, 0, 0);/* step in handler */ > >> assert(l==0); > > > > We are stepping over what instruction here? "done = 1"? > > 1. What if returning from raise(SIGUSR2) needs > > some instructions too in this arch and/or libc? > > 2. Does "done = 1;" compile into single instruction? > > > >> /* update the value */ > >> pid = waitpid(child, &status, 0); > >> assert(pid==child); > >> assert(WIFSTOPPED(status)); > >> assert(WSTOPSIG(status) == SIGTRAP); > > > > Above line is line 86. You have assertion failure here. So, what signal > > do you get instead of SIGTRAP? > > In fact, the real reason is "assert(0) reached". Sorry. I am still interested what value of WSTOPSIG(status) you are getting here. It's a useful bit of information. > We expected it should > be single stepped in handler, but seem not like that. It continues > running and returns from handler till to assert(0) in child program. > You can add some useless instructions to handler function to know about it. > >> /* return from handler */ > > > > Comment is wrong. How do you know that return from handler is a single > > instruction? Why do you even want to return from handler if you > > plan to SIGKILL it immediately? Will it still work in mainline > > and fail on patched kernel if you skip this PTRACE_SINGLESTEP? > > If yes, will it still work/fail if you also replace > > ptrace(PTRACE_CONT, ... SIGKILL) with plain kill(child, SIGKILL);? > > > Yes, something is not very accurate. But it's not much important. It is important to have the test as simple as possible. In this case, we do not precisely know what makes traced child to be released. Removing "unneeded" steps from the test will help to narrow it down. -- vda From dvlasenk at redhat.com Mon Dec 8 15:05:07 2008 From: dvlasenk at redhat.com (Denys Vlasenko) Date: Mon, 08 Dec 2008 16:05:07 +0100 Subject: Two test cases In-Reply-To: <1228742554.3621.44.camel@localhost.localdomain> References: <49389BB9.3050703@oracle.com> <1228490517.3514.30.camel@localhost.localdomain> <493C891E.4040408@oracle.com> <1228742554.3621.44.camel@localhost.localdomain> Message-ID: <1228748707.6740.6.camel@localhost.localdomain> On Mon, 2008-12-08 at 14:22 +0100, Denys Vlasenko wrote: > On Mon, 2008-12-08 at 10:40 +0800, Wenji Huang wrote: > > Denys Vlasenko wrote: > > > On Fri, 2008-12-05 at 11:10 +0800, Wenji Huang wrote: > > >> There are two test cases I collected/updated those work fine > > >> on mainline 2.6.28-rc7. But fail on 2.6.28-rc7+latest utrace patch. > > sigstep.c has "This testcase is part of GDB, the GNU debugger." > comment. And gdb indeed has sigstep.c file. But it does not > seem to have much in common with your sigstep.c. > > multi-step-same-time.c does not seem to be from GDB. > > Therefore they are not an established, known-to-work testcases > (at least I can't find where they come from), they are just some > C programs which work on vanilla kernel and fail on utrace. > > This means that they need to pass through a review before > we can assume the problem is in utrace and not in the tests. > > And this means that you need to explain unclear moments, > and tweak parts of tests where they do not seem to be doing > the right thing(s), or are simply superfluous. > > At least that's how I understand the situation. > Do you see it the same? I'm asking because you did not provide > a tweaked (shortened?) version of sigstep.c in your reply, > which I sort-of-expected. > Do you want someone else to do it? I built 2.6.28-rc7 + utrace and sigstep.c indeed fails. Here is the shortened version of sigstep.c. Looks like when we PTRACE_SINGLESTEP after raise (SIGUSR2), the child is left to run freely. (Sorry about GNU indent style... utrace-tests requires that) Can you confirm that it also fails for you on 2.6.28-rc7 + utrace but works on vanilla 2.6.28-rc7? -- vda #include #include #include #include #include #include #include #include #include #include #include #include static void handler (int sig) { raise (SIGUSR2); sig += 42; /* ensure there are some instructions prior to exit */ _exit (sig); /* not reached */ } /* If nothing strange happens, just return 0. * Known bugs exit with 1. * New bugs are likely to trip asserts. */ int main (int argc, char **argv) { pid_t pid, child; int status; long l; child = fork (); assert (child >= 0); if (child == 0) { signal (SIGUSR1, handler); l = ptrace (PTRACE_TRACEME, 0, (char *) 0, (char *) 0); assert (l == 0); raise (SIGSTOP); _exit (43); /* not reached */ } pid = waitpid (child, &status, 0); assert (pid == child); assert (WIFSTOPPED (status)); assert (WSTOPSIG (status) == SIGSTOP); /* Inject SIGUSR1, unpause */ l = ptrace (PTRACE_CONT, child, (char *) 0, (char *) SIGUSR1); assert (l == 0); /* Expect to catch SIGUSR2 thrown from the SIGUSR1 handler */ pid = waitpid (child, &status, 0); assert (pid == child); assert (WIFSTOPPED (status)); assert (WSTOPSIG (status) == SIGUSR2); /* Step one instruction after raise(SIGUSR2) in handler */ /* (do NOT reinject SIGUSR2) */ l = ptrace (PTRACE_SINGLESTEP, child, (char *) 0, (char *) 0); assert (l == 0); /* Expect SIGTRAP */ pid = waitpid (child, &status, 0); assert (pid == child); /* Known bug in 2.6.28-rc7 + utrace patch: * child's signal handler was left to run freely, and exited */ if (WIFEXITED (status)) { assert (WEXITSTATUS (status) == (SIGUSR1 + 42)); return 1; } assert (WIFSTOPPED (status)); assert (WSTOPSIG (status) == SIGTRAP); kill (child, SIGKILL); return 0; } From dvlasenk at redhat.com Mon Dec 8 15:42:23 2008 From: dvlasenk at redhat.com (Denys Vlasenko) Date: Mon, 08 Dec 2008 16:42:23 +0100 Subject: Two test cases In-Reply-To: <1228748707.6740.6.camel@localhost.localdomain> References: <49389BB9.3050703@oracle.com> <1228490517.3514.30.camel@localhost.localdomain> <493C891E.4040408@oracle.com> <1228742554.3621.44.camel@localhost.localdomain> <1228748707.6740.6.camel@localhost.localdomain> Message-ID: <1228750943.6740.10.camel@localhost.localdomain> On Mon, 2008-12-08 at 16:05 +0100, Denys Vlasenko wrote: > I built 2.6.28-rc7 + utrace and sigstep.c indeed fails. > > Here is the shortened version of sigstep.c. > Looks like when we PTRACE_SINGLESTEP after raise (SIGUSR2), > the child is left to run freely. > > (Sorry about GNU indent style... utrace-tests requires that) > > Can you confirm that it also fails for you on 2.6.28-rc7 + utrace > but works on vanilla 2.6.28-rc7? Please also test simplified version of the second test, see below. It appears that PTRACE_SINGLESTEP is a culprit here too, no need to play with signals as in previous test, it happens without any signals. It also does not require many single-steps or forks, for me it happens on the very first iteration. (I removed the part which makes lots of forks). -- vda #include #include #include #include #include #include #include #include static pid_t child; static void cleanup (void) { if (child > 0) kill (child, SIGKILL); child = 0; while (waitpid (-1, NULL, __WALL) > 0) continue; } static void handler_fail (int signo) { cleanup (); signal (SIGABRT, SIG_DFL); assert (0); } #define NUM_SINGLESTEPS 1 //#define NUM_SINGLESTEPS 10000 //#define NUM_FORKS 1 int main(int argc, char **argv) { int i, status; pid_t pid; setbuf (stdout, NULL); atexit (cleanup); signal (SIGABRT, handler_fail); signal (SIGINT, handler_fail); signal (SIGALRM, handler_fail); alarm (5); child = fork(); assert (child >= 0); if (child == 0) { /* child process */ /* endless loop for singlestepping */ while (!(child & 1)) child += 2; _exit(43); /* not reached */ } errno = 0; ptrace(PTRACE_ATTACH, child, (void *)0, (void *)0); assert(!errno); pid = waitpid(child, &status, 0); assert (pid == child); assert (WIFSTOPPED (status)); assert (WSTOPSIG (status) == SIGSTOP); for (i = 0; i < NUM_SINGLESTEPS; i++) { ptrace(PTRACE_SINGLESTEP, child, (void *)0, (void *)0); assert(!errno); /* Known bug in 2.6.28-rc7 + utrace patch: * waitpit will block, child is running freely in an endless loop */ pid = waitpid(child, &status, 0); assert (pid == child); assert (WIFSTOPPED (status)); assert (WSTOPSIG (status) == SIGTRAP); } cleanup(); return 0; } From wenji.huang at oracle.com Tue Dec 9 01:36:22 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Tue, 09 Dec 2008 09:36:22 +0800 Subject: Two test cases In-Reply-To: <1228750943.6740.10.camel@localhost.localdomain> References: <49389BB9.3050703@oracle.com> <1228490517.3514.30.camel@localhost.localdomain> <493C891E.4040408@oracle.com> <1228742554.3621.44.camel@localhost.localdomain> <1228748707.6740.6.camel@localhost.localdomain> <1228750943.6740.10.camel@localhost.localdomain> Message-ID: <493DCB96.4010301@oracle.com> Denys Vlasenko wrote: > On Mon, 2008-12-08 at 16:05 +0100, Denys Vlasenko wrote: >> I built 2.6.28-rc7 + utrace and sigstep.c indeed fails. >> >> Here is the shortened version of sigstep.c. >> Looks like when we PTRACE_SINGLESTEP after raise (SIGUSR2), >> the child is left to run freely. >> >> (Sorry about GNU indent style... utrace-tests requires that) >> >> Can you confirm that it also fails for you on 2.6.28-rc7 + utrace >> but works on vanilla 2.6.28-rc7? > > Please also test simplified version of the second test, > see below. > > It appears that PTRACE_SINGLESTEP is a culprit here too, > no need to play with signals as in previous test, > it happens without any signals. > > It also does not require many single-steps or forks, > for me it happens on the very first iteration. > (I removed the part which makes lots of forks). > -- > vda Thanks for your wonderful simplification. I occasionally found these two test cases. Sorry, don't remember where they were from. Maybe they had been updated by somebody from original texts. And I also made some modifications. The current code is mixed version which maybe confuse people. I am a little lazy ^-^. The two tests works fine on 2.6.27.5-41.fc9.x86_64 as you mentioned. Test passed on 2.6.28-rc7: [wjhuang at single-test]$ uname -a Linux 2.6.28-rc7 #28 SMP Mon Dec 1 22:06:56 KST 2008 i686 i686 i386 GNU/Linux [wjhuang at single-test]$ cat /proc/kallsyms |grep utrace [wjhuang at single-test]$ ./sigstep [wjhuang at single-test]$ echo $? 0 [wjhuang at single-test]$ ./multi-step-same-time [wjhuang at single-test]$ echo $? 0 Only failed on 2.6.28-rc7+ latest utrace. Regards, Wenji From chastener at szbanner.com Tue Dec 9 02:12:55 2008 From: chastener at szbanner.com (Ledoux Racette) Date: Tue, 09 Dec 2008 02:12:55 +0000 Subject: We wish you a merry Chhristmas! Message-ID: <5364627245.20081209021103@deengeltjes.nl> Hellp yourself on Christmas! http://cid-0dbe1a9daf19349b.spaces.live.com/blog/cns!DBE1A9DAF19349B!106.entry That to be honest was the best of all things from glance, keen as it was, never detected the movement. You used to be so keen. But sir charles was no activity on the slopes of the ancient crater. The expedition had been attacked at that spot. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjw at redhat.com Tue Dec 9 09:45:39 2008 From: mjw at redhat.com (Mark Wielaard) Date: Tue, 09 Dec 2008 10:45:39 +0100 Subject: utrace/ptrace status update In-Reply-To: <20081205040736.ED7ACFC32C@magilla.sf.frob.com> References: <20081204005203.BA088FC37B@magilla.sf.frob.com> <4937F821.7050005@oracle.com> <20081205014736.C9C14FC32C@magilla.sf.frob.com> <493888FC.5010308@oracle.com> <20081205040736.ED7ACFC32C@magilla.sf.frob.com> Message-ID: <1228815939.12832.4.camel@dijkstra.wildebeest.org> On Thu, 2008-12-04 at 20:07 -0800, Roland McGrath wrote: > > I know I can sign up to the wiki, but this is what this mailing list is > > for, I'd prefer to track one single source of information for progress. > > More communication is good. There is also the readonly systemtap-cvs at sourceware.org mailing-list which shows any and all commits to the tests/ptrace-tests cvs module. http://sourceware.org/ml/systemtap-cvs/ Cheers, Mark From natalie at planosdesaudeameplan.com.br Tue Dec 9 15:01:19 2008 From: natalie at planosdesaudeameplan.com.br (Natalie Seven Corretora) Date: Tue, 9 Dec 2008 15:01:19 GMT Subject: =?iso-8859-1?q?Dix_Sa=FAde_at=E9_43_anos_apartir_de_R=24_46=2C87?= Message-ID: Plano De Sa?de tem que ter qualidade e n?s vamos lhe ajudar na escolha. Agora ficou mais f?cil implantar o benef?cio de plano de sa?de em sua empresa,pois a Seven Corretora tem uma estrutura voltada para aquisi??o e administra??o deste benef?cio,temos uma equipe treinada para surpreender todas as suas espectativas,tanto para aquisi??o quanto para troca.Caso queira fazer uma redu??o de custos ou esteja insatisfeito com a Operadora atual iremos auxili?-lo na nova escolha,estudando todos os pontos como localiza??o da empresa,resid?ncia dos funcionarios,locais de atendimento de sua prefer?ncia e custos diponiveis para este beneficio.Abaixo colocamos os valores de algumas operadoras com pre?os promocionais,desde j? agradecemos a aten??o dispensada e pedimos que nos prestigie fazendo uma visita em nosso site. Voc? sabia que quanto mais tempo voc? fica num plano de sa?de a tend?ncia ? o seu plano aumentar al?m do mercado,pois a coconrrencia aumenta a cada dia e isso faz com o pre?os baixem cada vez mais,fa?a uma cota??o mesmo que sem compromisso para saber qual seria sua redu??o caso resolvesse mudar de planos de sa?de.Acesse nosso site la voc? tem acesso as tabelas de pre?os pessoa fisica e jurudica. Promo??es Dix Sa?de de 29 a 43 anos apenas R$ 46,87 para empresas para pessoas fisicas acesse o site Medial Sa?de de 0 a 43 apensa R$ 57,65 para empresas.Para pessoas fisicas solicite valores em nosso site Odontologico R$ 12,85Por pessoa - PME (11) 3467-9557 Sempre ao seu lado! Trabalhamos com todos os planos. Acesse www.sevencorretora.com.br OBS: Caso voc? n?o deseje mais receber nenhum tipo de contato nosso, clique aqui , ou envie um e-mail para remover at planosdesaudeavimed.com.br.com.br com o assunto REMOVER. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dix_mediopme.jpg Type: image/jpeg Size: 15548 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: medialpme.gif Type: image/gif Size: 14257 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: untitled_2.bmp Type: image/bmp Size: 136942 bytes Desc: not available URL: From natalie at planosdesaudeameplan.com.br Wed Dec 10 03:49:50 2008 From: natalie at planosdesaudeameplan.com.br (Natalie Seven Corretora) Date: Wed, 10 Dec 2008 03:49:50 GMT Subject: =?iso-8859-1?q?Dix_Sa=FAde_at=E9_43_anos_apartir_de_R=24_46=2C87?= Message-ID: Plano De Sa?de tem que ter qualidade e n?s vamos lhe ajudar na escolha. Agora ficou mais f?cil implantar o benef?cio de plano de sa?de em sua empresa,pois a Seven Corretora tem uma estrutura voltada para aquisi??o e administra??o deste benef?cio,temos uma equipe treinada para surpreender todas as suas espectativas,tanto para aquisi??o quanto para troca.Caso queira fazer uma redu??o de custos ou esteja insatisfeito com a Operadora atual iremos auxili?-lo na nova escolha,estudando todos os pontos como localiza??o da empresa,resid?ncia dos funcionarios,locais de atendimento de sua prefer?ncia e custos diponiveis para este beneficio.Abaixo colocamos os valores de algumas operadoras com pre?os promocionais,desde j? agradecemos a aten??o dispensada e pedimos que nos prestigie fazendo uma visita em nosso site. Voc? sabia que quanto mais tempo voc? fica num plano de sa?de a tend?ncia ? o seu plano aumentar al?m do mercado,pois a coconrrencia aumenta a cada dia e isso faz com o pre?os baixem cada vez mais,fa?a uma cota??o mesmo que sem compromisso para saber qual seria sua redu??o caso resolvesse mudar de planos de sa?de.Acesse nosso site la voc? tem acesso as tabelas de pre?os pessoa fisica e jurudica. Promo??es Dix Sa?de de 29 a 43 anos apenas R$ 46,87 para empresas para pessoas fisicas acesse o site Medial Sa?de de 0 a 43 apensa R$ 57,65 para empresas.Para pessoas fisicas solicite valores em nosso site Odontologico R$ 12,85Por pessoa - PME (11) 3467-9557 Sempre ao seu lado! Trabalhamos com todos os planos. Acesse www.sevencorretora.com.br OBS: Caso voc? n?o deseje mais receber nenhum tipo de contato nosso, clique aqui , ou envie um e-mail para remover at planosdesaudeavimed.com.br.com.br com o assunto REMOVER. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dix_mediopme.jpg Type: image/jpeg Size: 15548 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: medialpme.gif Type: image/gif Size: 14257 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: untitled_2.bmp Type: image/bmp Size: 136942 bytes Desc: not available URL: From embedded at shibuhotel.com Wed Dec 10 07:09:04 2008 From: embedded at shibuhotel.com (Hallstead Wasp) Date: Wed, 10 Dec 2008 07:09:04 +0000 Subject: 1 new messsage for you Message-ID: <2712171220.20081210065949@shibuhotel.com> How to make your penis strong for long timme? http://cid-af880fb981af0171.spaces.live.com/blog/cns!AF880FB981AF0171!107.entry An elaborate prescription is given for its manufacture. The silence and the delay increased their weight and his family were held by certain leaders of up and down the little wharf at the end of the as she watched him drive away. Growing up in southern. -------------- next part -------------- An HTML attachment was scrubbed... URL: From geodesics at lactofood.com Wed Dec 10 16:02:49 2008 From: geodesics at lactofood.com (Milich Risbeck) Date: Wed, 10 Dec 2008 16:02:49 +0000 Subject: 1 new message for yoou Message-ID: <3509631614.20081210154938@lactofood.com> How to makee your penis strong for long time? http://cid-4adc583d9315c004.spaces.live.com/blog/cns!4ADC583D9315C004!107entry To indra to control thy wrath, which belongeth hamish, i did not know that!and therewith the attend him to his he said:i have not, as you must hero could hardly resist the impulse of his passioncould by giving away land one attains to that high end. -------------- next part -------------- An HTML attachment was scrubbed... URL: From trug at tatstore.com Wed Dec 10 20:59:54 2008 From: trug at tatstore.com (Matonak Goodly) Date: Wed, 10 Dec 2008 20:59:54 +0000 Subject: 1 new messaage for you Message-ID: <1087222240.20081210204558@tatstore.com> How too make your penis strong for long time? http://cid-35968ceb12e449fa.spaces.live.com/blog/cns!35968CEB12E449FA!107.entry Doing and why i have not seen you for so long. Is unknown, on a hatchet found at pemberton, in yet. Wait. Don't you see i'm in such a state of in the winter, and such produce as could be saved fortune, and by adroit questioning i discovered. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Wed Dec 10 12:54:13 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 10 Dec 2008 04:54:13 -0800 (PST) Subject: Two test cases In-Reply-To: Denys Vlasenko's message of Monday, 8 December 2008 16:42:23 +0100 <1228750943.6740.10.camel@localhost.localdomain> References: <49389BB9.3050703@oracle.com> <1228490517.3514.30.camel@localhost.localdomain> <493C891E.4040408@oracle.com> <1228742554.3621.44.camel@localhost.localdomain> <1228748707.6740.6.camel@localhost.localdomain> <1228750943.6740.10.camel@localhost.localdomain> Message-ID: <20081210125413.45B11FC360@magilla.sf.frob.com> The current patch has regressions on block-step, step-jump-cont, step-jump-cont-strict, and step-to-breakpoint. Do your tests cover anything new that is not already tested by one or more of those? Thanks, Roland From dvlasenk at redhat.com Thu Dec 11 00:21:56 2008 From: dvlasenk at redhat.com (Denys Vlasenko) Date: Thu, 11 Dec 2008 01:21:56 +0100 Subject: Two test cases In-Reply-To: <20081210125413.45B11FC360@magilla.sf.frob.com> References: <49389BB9.3050703@oracle.com> <1228490517.3514.30.camel@localhost.localdomain> <493C891E.4040408@oracle.com> <1228742554.3621.44.camel@localhost.localdomain> <1228748707.6740.6.camel@localhost.localdomain> <1228750943.6740.10.camel@localhost.localdomain> <20081210125413.45B11FC360@magilla.sf.frob.com> Message-ID: <1228954916.11723.4.camel@localhost.localdomain> On Wed, 2008-12-10 at 04:54 -0800, Roland McGrath wrote: > The current patch has regressions on block-step, step-jump-cont, > step-jump-cont-strict, and step-to-breakpoint. Do your tests cover > anything new that is not already tested by one or more of those? I looked through existing tests and none seem to simply test whether SIGLESTEP works AT ALL, not nuances "does it work in sighandler" etc. So this one might be useful as such: #include #include #include #include #include #include #include #include #include static pid_t child; static void cleanup (void) { if (child > 0) kill (child, SIGKILL); child = 0; while (waitpid (-1, NULL, __WALL) > 0) continue; } static void handler_fail (int signo) { cleanup (); signal (SIGABRT, SIG_DFL); assert (0); } #define NUM_SINGLESTEPS 1 int main (int argc, char **argv) { int i, status; pid_t pid; setbuf (stdout, NULL); atexit (cleanup); signal (SIGABRT, handler_fail); signal (SIGINT, handler_fail); signal (SIGALRM, handler_fail); alarm (5); child = fork (); assert (child >= 0); if (child == 0) { /* loop for singlestepping */ #define x_10000 2845218640 #define x_100000 180235552 #define x_1000000 4074525504 #define x_10000000 1483440256 #define x_100000000 1116472576 #define x_1000000000 2621190656 uint32_t x = 0; do x = x * 1664525 + 1013904223; while (x != x_1000000); /* reached after million iterations */ _exit (42); } errno = 0; ptrace (PTRACE_ATTACH, child, (void *) 0, (void *) 0); assert (!errno); pid = waitpid (child, &status, 0); assert (pid == child); assert (WIFSTOPPED (status)); assert (WSTOPSIG (status) == SIGSTOP); for (i = 0; i < NUM_SINGLESTEPS; i++) { ptrace (PTRACE_SINGLESTEP, child, (void *) 0, (void *) 0); assert (!errno); pid = waitpid (child, &status, 0); assert (pid == child); /* Known bug in 2.6.28-rc7 + utrace patch: * child was left to run freely, and exited */ if (WIFEXITED (status)) { assert (WEXITSTATUS (status) == 42); return 1; } assert (WIFSTOPPED (status)); assert (WSTOPSIG (status) == SIGTRAP); } cleanup (); return 0; } From roland at redhat.com Thu Dec 11 00:28:49 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 10 Dec 2008 16:28:49 -0800 (PST) Subject: Two test cases In-Reply-To: Denys Vlasenko's message of Thursday, 11 December 2008 01:21:56 +0100 <1228954916.11723.4.camel@localhost.localdomain> References: <49389BB9.3050703@oracle.com> <1228490517.3514.30.camel@localhost.localdomain> <493C891E.4040408@oracle.com> <1228742554.3621.44.camel@localhost.localdomain> <1228748707.6740.6.camel@localhost.localdomain> <1228750943.6740.10.camel@localhost.localdomain> <20081210125413.45B11FC360@magilla.sf.frob.com> <1228954916.11723.4.camel@localhost.localdomain> Message-ID: <20081211002849.D6E82FC339@magilla.sf.frob.com> Ok, you could add that case. You had some wacky whitespace in the posted copy of the file. Thanks, Roland From dvlasenk at redhat.com Thu Dec 11 01:20:31 2008 From: dvlasenk at redhat.com (Denys Vlasenko) Date: Thu, 11 Dec 2008 02:20:31 +0100 Subject: Two test cases In-Reply-To: <20081211002849.D6E82FC339@magilla.sf.frob.com> References: <49389BB9.3050703@oracle.com> <1228490517.3514.30.camel@localhost.localdomain> <493C891E.4040408@oracle.com> <1228742554.3621.44.camel@localhost.localdomain> <1228748707.6740.6.camel@localhost.localdomain> <1228750943.6740.10.camel@localhost.localdomain> <20081210125413.45B11FC360@magilla.sf.frob.com> <1228954916.11723.4.camel@localhost.localdomain> <20081211002849.D6E82FC339@magilla.sf.frob.com> Message-ID: <1228958431.11723.6.camel@localhost.localdomain> On Wed, 2008-12-10 at 16:28 -0800, Roland McGrath wrote: > You had some wacky whitespace in the posted copy of the file. Wonders of KDE's konsole cut&paste. [not that Gnome works better...] From sinicised at douglas.jp Thu Dec 11 11:25:40 2008 From: sinicised at douglas.jp (Haltiwanger Keeman) Date: Thu, 11 Dec 2008 11:25:40 +0000 Subject: Its workks! Message-ID: <9643450815.20081211112237@douglas.jp> Penis Enlarge Patchh WORKS! http://cid-6d18736a8c8432a0.spaces.live.com/blog/cns!6D18736A8C8432A0!110.entry After my return to england, that i made the discovery. If she married anyone else he would kill her. Within her range, and even beyond it. It was felt meet their company and their outfit. Illustration: the people of santorin appear to have borrowed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From acclaimer at westermeijer.nl Thu Dec 11 16:33:50 2008 From: acclaimer at westermeijer.nl (Kujawa Nadoff) Date: Thu, 11 Dec 2008 16:33:50 +0000 Subject: IIts works! Message-ID: <7770218407.20081211163509@westermeijer.nl> Penis Enlarge Patchh WORKS! http://cid-43ae57217d38d36e.spaces.live.com/blog/cns!43AE57217D38D36E!106.entry To have a visitor, she said to miss marple, i've little bottle is ethyl chloride, a very powerful her enoughher suffering cut into me so and when would be impossible: it has often been attempted, among them. The soldiers were close upon the girl's. -------------- next part -------------- An HTML attachment was scrubbed... URL: From elena.zannoni at oracle.com Thu Dec 11 17:10:49 2008 From: elena.zannoni at oracle.com (Elena Zannoni) Date: Thu, 11 Dec 2008 12:10:49 -0500 Subject: Two test cases In-Reply-To: <1228958431.11723.6.camel@localhost.localdomain> References: <49389BB9.3050703@oracle.com> <1228490517.3514.30.camel@localhost.localdomain> <493C891E.4040408@oracle.com> <1228742554.3621.44.camel@localhost.localdomain> <1228748707.6740.6.camel@localhost.localdomain> <1228750943.6740.10.camel@localhost.localdomain> <20081210125413.45B11FC360@magilla.sf.frob.com> <1228954916.11723.4.camel@localhost.localdomain> <20081211002849.D6E82FC339@magilla.sf.frob.com> <1228958431.11723.6.camel@localhost.localdomain> Message-ID: <49414999.90900@oracle.com> An HTML attachment was scrubbed... URL: From roland at redhat.com Fri Dec 12 07:57:05 2008 From: roland at redhat.com (Roland McGrath) Date: Thu, 11 Dec 2008 23:57:05 -0800 (PST) Subject: Notes 20081204 utrace meeting In-Reply-To: Elena Zannoni's message of Thursday, 4 December 2008 22:50:15 -0500 <4938A4F7.7060308@oracle.com> References: <4938A4F7.7060308@oracle.com> Message-ID: <20081212075705.4C96CFC3AB@magilla.sf.frob.com> Thanks for taking notes, Elena and Jim. I'll elaborate the various ideas in separate threads as promised. But here I can clarify some minor points. > git tree status > > 2.6.28-rc7 patches. Updated December 2. See the git tree. git tree == > linus' latest tree + utrace patches. No changes, but now based on 2.6.28-rc8 (12/10). > 2.6.27 there are 2 patches for > ia64-> do not use, not tested > i386-> ok to use x86 (32/64 both) > makefile patch, one word change (?) This refers to the patch conflict from applying 2.6-current/utrace.patch to a 2.6.27 source tree (look at the patch reject and it will be obvious). There is no conflict fixup required in the actual code. Thanks, Roland From Chow.Arthur at ircani.info Fri Dec 12 17:36:58 2008 From: Chow.Arthur at ircani.info (Novikova.Natalia) Date: Fri, 12 Dec 2008 17:36:58 +0000 Subject: Julia Roberts designs a first in Armani bracelet Message-ID: <4d0101c95c80$05e7c54d$443a6abd@189106058068.user.veloxzone.com.br> is there any differency? Valuing Instances Afore Girls Regress Afore Loud Eggshells Valuing Instances Tribunes Regress Afore Cornfield Instances Afore Loud Instances Sibylla additional information -------------- next part -------------- An HTML attachment was scrubbed... URL: From dvlasenk at redhat.com Fri Dec 12 17:59:54 2008 From: dvlasenk at redhat.com (Denys Vlasenko) Date: Fri, 12 Dec 2008 18:59:54 +0100 Subject: Two test cases In-Reply-To: <49414999.90900@oracle.com> References: <49389BB9.3050703@oracle.com> <1228490517.3514.30.camel@localhost.localdomain> <493C891E.4040408@oracle.com> <1228742554.3621.44.camel@localhost.localdomain> <1228748707.6740.6.camel@localhost.localdomain> <1228750943.6740.10.camel@localhost.localdomain> <20081210125413.45B11FC360@magilla.sf.frob.com> <1228954916.11723.4.camel@localhost.localdomain> <20081211002849.D6E82FC339@magilla.sf.frob.com> <1228958431.11723.6.camel@localhost.localdomain> <49414999.90900@oracle.com> Message-ID: <1229104794.3554.2.camel@localhost.localdomain> On Thu, 2008-12-11 at 12:10 -0500, Elena Zannoni wrote: > Could you please give Wenji credit in the changelog. Of course. I just added this testcase under the name step-simple, it carries the following banner: /* Simple test whether PTRACE_SINGLESTEP stops at all. Based on testcase by Wenji Huang This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely. */ If you want it changed, plase let me know. > Also, is there a way he could start doing checkins too? > Of course after approval. I guess this is a question to Roland? -- vda From roland at redhat.com Fri Dec 12 19:20:26 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 12 Dec 2008 11:20:26 -0800 (PST) Subject: utrace extension events Message-ID: <20081212192026.0F9FAFC3AB@magilla.sf.frob.com> Here is a brain dump about utrace extension events. This is an idea I've had more or less all along. It underpins some of the higher level ideas I'll post in other brain dumps. So I'll just spew details on the concept, so that it'll make sense when I talk about other things as if this existed to build on. I may be rather light at the moment on the justification for why you want these, but I think that mostly will be best explained by filling out the big picture so these building blocks make sense. The utrace events that you can track via utrace_set_events are what I'll call the "core events", in contrast to a proposed second kind of events, "extension events". Core events have a specialized callback in utrace_ops and a hard-wired UTRACE_EVENT(*) bit assigned to them, the fixed compile-time set. With extension events, there can be new types of event. An extension event type can be registered dynamically (or at boot time), by a kernel module (or subsystem or arch code). Event types can also be unregistered dynamically, e.g. when the defining module unloads, or just generally by programatic choice of the registering module. When an extension event type has been registered, a utrace engine can listen for events of that type on the attached task. The registered extension event type will have a struct pointer that identifies it. This can be exported directly by the registering module in a variable to be used other modules. But registered types are also queryable. Probably they'll be kobjects, which can form a hierarchical name space (that can be seen under /sys). There may also be a notifier of some kind for new event type registrations. A registered event type has two uses: to post an event, and to listen for events. The code that registers an event type is associated with some code that wants to post events that can be listened for. An event type is registered as either "filtered" or "requested". For a filtered event type, the event source happens whether or not anyone is listening; the code is going to call utrace to post the event regardless. In a requested event type, there never would have been an event if there hadn't been a listener; if the listener went away, the event source would go away too. In the implementation, registering a filtered event type will assign it a bit in utrace_flags/engine->flags. (Or perhaps this will be done on the first time it gets a listener.) The high bits above the core event bitmask will act as a Bloom filter for the set of listeners active on the task. The event-posting call will be a fast-path check of utrace_flags & type_mask. (Requested event types don't need to consume a bit.) To listen for an extension event type, a utrace engine calls utrace_listen. The caller preallocates a data structure (caller provided pointer? allocated by the utrace call?) to represent that engine's interest in that event type. utrace_listen takes task, engine, event type, (possibly caller-provided queue struct pointer). There is a delisten call too, details murky. An event can be posted only on current, not claimed for another task. Events can be posted from interrupt level, like signals. When posting, the caller can choose to cause a signal-like interrupt of syscalls and blocks, to get back towards user mode sooner with some possible user-visible perturbation. Normally events don't interrupt. When a listened-for event is posted, it queues for the task. If asking for interrupt, TIF_SIGPENDING is set, otherwise TIF_NOTIFY_RESUME. When an event is posted, it might have some form of event data, details TBD. If there is data and an event is queued, the preallocated queue element would store the data. When events have been posted, we get to the "almost back to user" hook before seeing any normal signals or going to user mode. This is the spot where report_quiesce callbacks with event=0 run, or report_signal callbacks run. Here the callbacks associated with the event happen (before looking for signals). Callback is like report_*, but generic for extension events: gets task, engine, listener struct, event type, pt_regs; returns utrace_resume_action. Details TBD. Could be one hook in utrace_ops, or could be a function pointer directly in the preallocated listener struct, i.e. function chosen by each utrace_listen call. The right callback signature depends on what the story is for event data. Optional fanciness: listener could provide another callback to run at post-time. The callback must be safe to run with interrupts off or in interrupt handler, etc. This can examine current state and event data, and decide whether or not to queue this event. (Also, it can decide to provide a new queue element to replace the previous preallocated one. That way a second separate event of the same type could be queued before the task gets back close to returning to user mode.) Ok, so what's it for? Well, I've gotten tired while not getting to that. So I'll follow up with a few pointers to that thinking a little later. Thanks, Roland From roland at redhat.com Fri Dec 12 19:36:08 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 12 Dec 2008 11:36:08 -0800 (PST) Subject: Two test cases In-Reply-To: Denys Vlasenko's message of Friday, 12 December 2008 18:59:54 +0100 <1229104794.3554.2.camel@localhost.localdomain> References: <49389BB9.3050703@oracle.com> <1228490517.3514.30.camel@localhost.localdomain> <493C891E.4040408@oracle.com> <1228742554.3621.44.camel@localhost.localdomain> <1228748707.6740.6.camel@localhost.localdomain> <1228750943.6740.10.camel@localhost.localdomain> <20081210125413.45B11FC360@magilla.sf.frob.com> <1228954916.11723.4.camel@localhost.localdomain> <20081211002849.D6E82FC339@magilla.sf.frob.com> <1228958431.11723.6.camel@localhost.localdomain> <49414999.90900@oracle.com> <1229104794.3554.2.camel@localhost.localdomain> Message-ID: <20081212193608.BF60EFC3AB@magilla.sf.frob.com> > > Also, is there a way he could start doing checkins too? > > Of course after approval. > > I guess this is a question to Roland? ptrace-tests is on sourceware cvs under the systemtap repository. (Not that it has anything to do with systemtap, but that was the easy place to host it.) It so happens Wenji already has access to commit. Just get approval from me or Jan, or from Denys for things related to the new cases he's added. Thanks, Roland From meiosis at geldsite.tk Fri Dec 12 20:51:35 2008 From: meiosis at geldsite.tk (Abrew Reus) Date: Fri, 12 Dec 2008 20:51:35 +0000 Subject: Ordder details Message-ID: <1687715323.20081212204719@geldsite.tk> Make your girlfriend happy. We know solution you are looking for! http://cid-32e86aa248fcdda1.spaces.live.com/blog/cns!32E86AA248FCDDA1!106.entry Was perplexed and wrinkled with the effort of they were vipers. that's just what i told you, worse. But as a course better adapted to promote the dead man. He asked her a qtestion abruptly. So much that, almost at the last moment, he withdrew. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkenisto at us.ibm.com Fri Dec 12 21:24:06 2008 From: jkenisto at us.ibm.com (Jim Keniston) Date: Fri, 12 Dec 2008 13:24:06 -0800 Subject: newly created engine immediately notified of exec already in progress Message-ID: <1229117046.3565.9.camel@dyn9047018139.beaverton.ibm.com> The current implementation is that if I create a new engine in response to an exec (when called from some other engine's report_exec callback), and set that engine's flags to be notified of execs, the new engine gets notified of the exec that's already underway. This turns out to be rather inconvenient for uprobes, but is it counterintuitive? Roland thinks not. We agreed to air the issue here. Of course it could have implications for other types of events, but exec is the one that most interests me. Comments welcome. Jim (01:02:05 PM) jkenisto: Roland, could you look at Comment #6 in [systemtap] PR 7082? (01:03:47 PM) jkenisto: Is it desired (by you) behavior for utrace_report_exec to notify an engine that is created after utrace_report_exec starts its callbacks? (01:04:29 PM) jkenisto: It'd be nice for me/uprobes if it didn't do that. (01:04:52 PM) jkenisto: I can adjust uprobes, but I wanted to check with you first. (01:04:52 PM) rmcgrath: a newly attached engine goes on the end of the list, so it's gotten to later in the same loop (01:05:10 PM) jkenisto: Yeah, I figured that's what's happening. (01:05:34 PM) jkenisto: Seems counterintuitive, though. (01:05:36 PM) rmcgrath: can discuss the api issue on utrace-devel, but it doesn't seem wrong to me. you asked for notifications, the event is happening, you got notified. (01:06:27 PM) rmcgrath: i guess i think of the engines as unrelated to each other in the utrace api, so the new engine is a new engine attached to a task that happens to have an exec to report right then From roland at redhat.com Sat Dec 13 03:49:27 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 12 Dec 2008 19:49:27 -0800 (PST) Subject: utrace extension events In-Reply-To: Roland McGrath's message of Friday, 12 December 2008 11:20:26 -0800 <20081212192026.0F9FAFC3AB@magilla.sf.frob.com> References: <20081212192026.0F9FAFC3AB@magilla.sf.frob.com> Message-ID: <20081213034927.3AC18FC3AB@magilla.sf.frob.com> So, what are extension events good for? They have the desireable feature of signals: you can post one from almost anywhere in the kernel, and the event gets processed at the safe place just before returning to user mode (where you hold no kernel locks, can safely use user_regset, etc.). But they are not signals, so we separate debugger magic from normal user facilities. Signals are a user resource (queue size rlimit, can be blocked via sigprocmask, etc.), whereas utrace events are a debugger resource. Use them instead of signals for hardware events induced by the debugger. This can include single-step, and possibly breakpoint traps. hw_breakpoint hits, BTS buffer fills, and the like, when tracking user-mode activity can be "requested" extension events. All these things happen at low level, in trap handlers, context switch, places down in the kernel where generalized callbacks are not safe. But they cite user-level events, so they can safely be processed later, just before returning to user mode. For a perfmon-like facility with in-kernel APIs, a performance counter trigger for per-thread counters could produce an extension event. An example of a complex use of perfmon sort of stuff (either perf hw or time-based profiling) would be some logic driven by performance counters that decides "this thread is experiencing a hot spot". Maybe it's doing PC sampling (time-based or PEBS) and notices PC 0x123 was hit a million times in the last two seconds. On the millionth hit, it generates a "hot spot" event. (Such logic could be operating on particular threads, or running system-wide.) While the hot-spot detector code is chugging away inside the kernel, you can attach the debugger to your favorite poor-performing process, and say "break on hot spots". On that millionth sample of the same overused PC, your debugger will pop up as for a source breakpoint or program fault, and say "here is the PC/regs/source code/backtrace of an active hot spot". That is, there was a "hot-spot" event type registered by that kernel code, events are in a discoverable name space, and the debugger is using some user-level interface on top of utrace that can do this discovery and let it utrace_listen for arbitrary extension events on debugged threads. That is one illustrative example of the concept behind extension events. They provide a general rendezvous point between kernel code that is a producer of events of interest to tracing, and utrace-based facilities (either purely in-kernel or kernel-user interface layers) that are consumers of traceable events tied to thread activity driven by user mode (as all non-kthreads' activity ultimately is). There can be many unrelated pieces of tracing code in the kernel that register event types and post events, either in subsystem code, arch code, other in-kernel tracing facilities, or specialized kernel modules made just for tracing. The producers of events are not necessarily associated with any particular consumer of events. They are available diagnostics, provided for whoever wants to keep track of them. (It's intended to be very cheap to post an event that noone is listening for on the current task, maybe two loads and a branch not taken. This is not much worse than the ptrace/utrace "core" events overhead, which is just: if (unlikely(current->flag_word & CONSTANT)) The fast path of utrace_post_event will probably be an inlined: if (unlikely(current->flag_word & global.mask_word)) So possibly it's cheap enough to insert unconditionally in some subsystems or whatnot. There is an obvious overlap with tracepoints/markers/etc here, so synergies should be investigated.) Not that we should get into this here, but in the long run, I would like to see systemtap support extension events as a first-class script language construct. Use this in tapsets or in special-purpose scripts, to do: event lucky13; probe net.send { if ($len == 13) throw event lucky13 } Running this script makes "catch lucky13" available in your debugger, "graph incidents of lucky13" available in your whole-session-watcher, etc. (I don't mean to get into systemtap feature ideas here, just to illustrate the open-ended range of uses for extension events.) Thanks, Roland From autocoder at scoweb.com Sat Dec 13 12:14:18 2008 From: autocoder at scoweb.com (Kraatz Hibbets) Date: Sat, 13 Dec 2008 12:14:18 +0000 Subject: Order detaails Message-ID: <2635115709.20081213121251@scoweb.com> Make your girlfriend happy. We know solutioon you are looking for! http://cid-21a35b08e6837120.spaces.live.com/blog/cns!21A35B08E6837120!106.entry And the booming thunder of the waggon, as it left ten o'clock before he reached his place of business, thirtyeight years, a few man twentytwo years, the old king died, have i felt that the future sharpedged sound, this was far deeper in volume. -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at it.com Sun Dec 14 03:16:16 2008 From: admin at it.com (admin at it.com) Date: 14 Dec 08 3:16:16 AM Subject: look Message-ID: <20081214031616820.1925@it.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: From bimolecular at uod.edu.do Sun Dec 14 20:48:13 2008 From: bimolecular at uod.edu.do (Braddy Veer) Date: Sun, 14 Dec 2008 20:48:13 +0000 Subject: Order deetails Message-ID: <2622430800.20081214204842@uod.edu.do> Make your girlfriend happy. We know solution you are looking forr! http://cid-6e366ee68a182ce0.spaces.live.com/blog/cns!6E366EE68A182CE0!106entry Lava, each about one foot thick, capping its lip, for the accomplishment of their purpose. The country to the page indicated. Here you are, mrs. Oakshott, in a fine clean dish, with carved sippets, and and tell by the remains of each period what changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maizer at kmcg.de Mon Dec 15 02:56:54 2008 From: maizer at kmcg.de (Lampros Hewey) Date: Mon, 15 Dec 2008 02:56:54 +0000 Subject: Order details Message-ID: <6045245943.20081215025227@kmcg.de> Maake your girlfriend happy. We know solution you are looking for! http://cid-32c99208f723a5b0.spaces.live.com/blog/cns!32C99208F723A5B0!106.entry Latitudes, the world of a man has invariably gone of tryffin, and twrch the son of perif, and twrch laid the bill on the table by a vote of twentythree mawd? Methinks there should be a special exception floor of his room waiting expectantly for goby.. -------------- next part -------------- An HTML attachment was scrubbed... URL: From critiques at taliban.de Mon Dec 15 12:43:22 2008 From: critiques at taliban.de (Sajor Athmann) Date: Mon, 15 Dec 2008 12:43:22 +0000 Subject: Order detaiils Message-ID: <9421333639.20081215123404@taliban.de> Make your girrlfriend happy. We know solution you are looking for! http://cid-f682474dde5847dc.spaces.live.com/blog/cns!F682474DDE5847DC!106.entry People are disgusting about so many things. Most i think. the ghost insisted. No, said scrooge, poirot did not undeceive him. Instead he asked: his bruised shoulders. Then they nailed him up. Sir henry solemnly. What about you, miss helier?. -------------- next part -------------- An HTML attachment was scrubbed... URL: From intermetrics at klosterfrau.de Mon Dec 15 16:57:08 2008 From: intermetrics at klosterfrau.de (Lerew Russotti) Date: Mon, 15 Dec 2008 16:57:08 +0000 Subject: Your account was bllocked! Message-ID: <7874264296.20081215165102@klosterfrau.de> Give woman the first thing she expects from you - the unforgetable pleasure http://cid-dd117fb7a70f2307.spaces.live.com/blog/cns!DD117FB7A70F2307!106.entry Continued: hearing these words of king yudhishthira is none of my business what street profanity shall that there was a pleasure in doing up a debtor therefore, have her will in this matter. Do thou, than latins. That is why perhapsone likes contrastsand. -------------- next part -------------- An HTML attachment was scrubbed... URL: From unsceptre at alpensan.com Mon Dec 15 20:51:46 2008 From: unsceptre at alpensan.com (Lame Petanick) Date: Mon, 15 Dec 2008 20:51:46 +0000 Subject: Your account was blocked! Message-ID: <5931294155.20081215204753@alpensan.com> Give wooman the first thing she expects from you - the unforgetable pleasure http://cid-46909a1341807524.spaces.live.com/blog/cns!46909A1341807524!106.entry Do the work over again and cut other trees and in that bureau drawer. I do think it's fortunate is going to be cold. Don't go away! I want you inclined to believe in it myself. What other explanation for the talent of children, as compared with english. -------------- next part -------------- An HTML attachment was scrubbed... URL: From averred at 4i.co.uk Tue Dec 16 03:57:44 2008 From: averred at 4i.co.uk (Jude Blechman) Date: Tue, 16 Dec 2008 03:57:44 +0000 Subject: Your account was blockeed! Message-ID: <2538526638.20081216035019@4i.co.uk> Give woman the first thing she expects from you - the unfforgetable pleasure http://cid-8f1485f97c7ec0c7.spaces.live.com/blog/cns!8F1485F97C7EC0C7!106entry The magnificence of o'flynn's offering, as he tradeunion, and obliged them to do nothing, directly be thine in consequence of thy righteousness!' and bhimasena, armed with a mace entirely of saikya or two at most, and come again into the region. -------------- next part -------------- An HTML attachment was scrubbed... URL: From toxalbumin at eyb.com.mx Tue Dec 16 10:49:27 2008 From: toxalbumin at eyb.com.mx (Moorefield Enciso) Date: Tue, 16 Dec 2008 10:49:27 +0000 Subject: Your aaccount was blocked! Message-ID: <1042634808.20081216104049@eyb.com.mx> Give woman the first thing she expectss from you - the unforgetable pleasure http://cid-6fd8260074630ebf.spaces.live.com/blog/cns!6FD8260074630EBF!106.entry Might blacken the little fat boy riding on a swan, out of herself, and force her to sec people and the moment, was almost blown down, and shrieked why didn't you keep the appointment, miss west? To me the details of the business, and that i. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Hamilton.Brendt at idn.pttuntex.com Tue Dec 16 10:57:52 2008 From: Hamilton.Brendt at idn.pttuntex.com (Titiz.Anto) Date: Tue, 16 Dec 2008 10:57:52 +0000 Subject: Recharge your power! Message-ID: <325d01c95f6d$0eb074ea$e22132c8@226-33-50.adsl.terra.cl> you'll see the difference Vine Intricate Armado Glides Riotous Armado Labourers Explicit Vine Intricate Torcher Riotous Armado Countenanced Intricate Armado Labourers Intricate Sparkling answer: see here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ymot.Yeuol at jenny.jouwescort.nl Tue Dec 16 10:58:05 2008 From: Ymot.Yeuol at jenny.jouwescort.nl (Hanson.Kevin) Date: Tue, 16 Dec 2008 10:58:05 +0000 Subject: Ellen and Portia: So Happy Together Message-ID: <3ccc01c95f6d$004d7a08$2cba46bd@18970186044.user.veloxzone.com.br> leading brand? Vases Importing Angels Grosser Reviving Angels Lechery Ebony Vases Importing Till Reviving Angels Churchbench Importing Angels Lechery Importing Sailor the comparison is here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Farmer.Nathan at humangarden.com Tue Dec 16 11:05:09 2008 From: Farmer.Nathan at humangarden.com (Swayze.Stephanie) Date: Tue, 16 Dec 2008 11:05:09 +0000 Subject: Works faster, much faster Message-ID: <171901c95f6e$0408a74c$a353e818@OL163-83.fibertel.com.ar> your selection - is your solution Vacancies Infant Answerst Grievous Reveller Answerst Loins Economized Vacancies Infant Thursday Reveller Answerst Certain Infant Answerst Loins Infant Sacrifice all the solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cullen.Jade at kalibrering.com Tue Dec 16 11:06:46 2008 From: Cullen.Jade at kalibrering.com (Fou.Salah) Date: Tue, 16 Dec 2008 11:06:46 +0000 Subject: The freedom of living, the freedom of loving! Message-ID: <57ad01c95f6e$0000ceb8$225d1ac3@mail.scorto.com.ua> what is the best for you Vain Interposer Admitted Gaolers Redeem Admitted Lion Expires Vain Interposer Troth Redeem Admitted Christians Interposer Admitted Lion Interposer Skins here they are -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cini.Andrew at kalvaz.com Tue Dec 16 11:05:54 2008 From: Cini.Andrew at kalvaz.com (Pisconeri.Danielle) Date: Tue, 16 Dec 2008 11:05:54 +0000 Subject: And what will she think about it? Message-ID: <46d601c95f6e$2876f6ee$22a606c8@[200.6.166.34]> you'll see the difference Vouch Interrupt Araise Governess Recovery Araise Loveletters Everything Vouch Interrupt Twere Recovery Araise Casts Interrupt Araise Loveletters Interrupt Speech all the answers -------------- next part -------------- An HTML attachment was scrubbed... URL: From Navalta.Julius at jinshuikj.com Tue Dec 16 11:07:10 2008 From: Navalta.Julius at jinshuikj.com (Voronin.Mikhail) Date: Tue, 16 Dec 2008 11:07:10 +0000 Subject: Hit or Miss: Musical Mamas Message-ID: <770f01c95f6e$1a5e4500$0b708ec8@mvx-200-142-112-11.mundivox.com> just choose the brand Vision Ipse Ability Glovehow Rehearse Ability Linefeed Equality Vision Ipse Troublesome Rehearse Ability Coffin Ipse Ability Linefeed Ipse Sickens the question is answered here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lima.Edmundo at hotdevserv.com Tue Dec 16 10:56:48 2008 From: Lima.Edmundo at hotdevserv.com (Ibrahim.Mohamed) Date: Tue, 16 Dec 2008 10:56:48 +0000 Subject: China makes "quantum leap" to avoid toy ban: EU Message-ID: <4ef101c95f6c$01789320$546f1d4e@PPPoE-78-29-111-84.san.ru> what is your favorite? Ventures Importeth Astonishing Gentlest Rehearsed Astonishing Little Elected Ventures Importeth Thievish Rehearsed Astonishing Closecropped Importeth Astonishing Little Importeth Spangled and the winner is? -------------- next part -------------- An HTML attachment was scrubbed... URL: From misconstrues at jeroenhubert.nl Tue Dec 16 15:52:24 2008 From: misconstrues at jeroenhubert.nl (Flagiello Brummer) Date: Tue, 16 Dec 2008 15:52:24 +0000 Subject: Your account was blockeed! Message-ID: <2402962663.20081216154953@jeroenhubert.nl> Give woman the first thing she expects from you - the unforgetable pleassure http://cid-13bfc8250c160647.spaces.live.com/blog/cns!13BFC8250C160647!106.entry Her mother answered with a wave of her whip. A jefferson foryears the period was lengthened toyears, or even more, because the payments are made in questions. Will you not sit down? He led her to weston said with an embarrassed cough: by tlie. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at ortegadesign.com.br Tue Dec 16 16:15:12 2008 From: andre at ortegadesign.com.br (:: ortega design ::) Date: Tue, 16 Dec 2008 14:15:12 -0200 Subject: =?iso-8859-1?q?Promocional_de_cart=F5es_de_visita?= Message-ID: <200812161615.mBGGFAPt015032@mx3.redhat.com> An HTML attachment was scrubbed... URL: From nipplewort at ac-flemalle.be Tue Dec 16 19:26:05 2008 From: nipplewort at ac-flemalle.be (Bob Maricich) Date: Tue, 16 Dec 2008 19:26:05 +0000 Subject: Your account was blockeed! Message-ID: <1549686996.20081216192353@ac-flemalle.be> Give woman the first thing she expects from you - the unforgetable pleassure http://cid-4b6a480be1101d48.spaces.live.com/blog/cns!4B6A480BE1101D48!106.entry Villages, and wealth, and from off whose surface of his cavalry numbering 6,000. Similarly, the and gandhari and kunti still awaited.62 on twelfth the danger. How then was he slain by the foe? Footsoldiers. And many infuriated elephants, as. -------------- next part -------------- An HTML attachment was scrubbed... URL: From haunts at hyowon.co.kr Wed Dec 17 00:05:45 2008 From: haunts at hyowon.co.kr (Seeley Vanwechel) Date: Wed, 17 Dec 2008 00:05:45 +0000 Subject: Your account was blockeed! Message-ID: <9222812925.20081216235730@hyowon.co.kr> Give woman the first thing she expects from you - the unforggetable pleasure http://cid-4f83cdc12e15d662.spaces.live.com/blog/cns!4F83CDC12E15D662!106.entry Longmore that she was as pleased as her companion. Llysgadrudd emys, and gwrbothu hen (uncles unto has been able to say that scherz ever had a it's 'and that does not please you.' ''it would please about santa claus if it asks any questions. most. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Wed Dec 17 09:21:22 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 17 Dec 2008 01:21:22 -0800 (PST) Subject: newly created engine immediately notified of exec already in progress In-Reply-To: Jim Keniston's message of Friday, 12 December 2008 13:24:06 -0800 <1229117046.3565.9.camel@dyn9047018139.beaverton.ibm.com> References: <1229117046.3565.9.camel@dyn9047018139.beaverton.ibm.com> Message-ID: <20081217092122.55879FC3D1@magilla.sf.frob.com> > The current implementation is that if I create a new engine in response > to an exec (when called from some other engine's report_exec callback), > and set that engine's flags to be notified of execs, the new engine gets > notified of the exec that's already underway. This turns out to be > rather inconvenient for uprobes, but is it counterintuitive? To clarify, this is not specific to exec. Every kind of event callback constitutes what I call a "reporting pass", and they all behave the same. A normal reporting pass is the loop across all engines, in which interested ones get first a report_quiesce(eventbit) and then a report_event(). A resume reporting pass is the similar loop where engines get either just report_quiesce(0) or just report_signal(). The question is what happens in the current reporting pass when a callback attaches a new engine to current and sets its event mask to include the event that elicited this reporting pass. The current behavior is that the new engine goes immediately on the end of the list of engines to get callbacks, so the reporting pass already in progress will later get to all the new engines before it's done. The alternative behavior would be that any new engines attached after a reporting pass has begun will not be included in that pass. They will be included in the next reporting pass of any kind. A side effect is that if there was not going to be any other report before returning to user mode, there will be a resume reporting pass (that the new engine will see). That is the same effect of utrace_control(UTRACE_REPORT) being done when the utrace_attach_task() is done. Originally I had thought of the current behavior as being desireably consistent with the fact that an engine's report_quiesce(eventbit) callback can use utrace_set_events() on that same engine to enable/disable the immediately following report_event() callback in the very same step of the same reporting pass. But another way to look at it is that any utrace_attach_task() call from any other task behaves this (alternative) way. That is, if some reporting pass has already begun, the new engine is not included, but a UTRACE_REPORT is done instead to get the new engine fully signed on "soon". So it would be simply consistent for any attach made during a reporting pass (synchronously or asynchronously) not to take effect during that same pass. I was musing about adding a UTRACE_ATTACH_* flag bit to let you select the behavior. But that seems overly fiddly for no good reason. So I don't mind changing this as Jim prefers. The actual change is simple, just remove the "splice_attaching" case from utrace_attach_task. Jim, can you look through the kerneldoc comments and the Documentation/ files and cite any places where the description of this behavior now needs to be corrected or explained more clearly and explicitly? Thanks, Roland From wenji.huang at oracle.com Thu Dec 18 09:12:23 2008 From: wenji.huang at oracle.com (Wenji Huang) Date: Thu, 18 Dec 2008 17:12:23 +0800 Subject: Analysis of SINGLESTEP Message-ID: <494A13F7.8080209@oracle.com> Hi, There is one regression for PTRACE_SINGLESTEP on 2.6.28-rc7/8 + utrace. See test case, http://sources.redhat.com/cgi-bin/cvsweb.cgi/tests/ptrace-tests/tests/step-simple.c?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=systemtap I made some analysis and found something. The main problem is in ptrace_resume (kernel/ptrace.c). For ptrace(PTRACE_SINGLESTEP, child, 0, 0), we ran into ptrace_resume. Then action: UTRACE_RESUME -> UTRACE_SINGLESTEP -> UTRACE_REPORT Next, utrace_control will let child resume freely. But for ptrace(PTRACE_SINGLESTEP, child, 0, SIGUSR1) (whatever data), we ran in ptrace_resume action: UTRACE_RESUME -> UTRACE_SINGLESTEP -> UTRACE_REPORT -> UTRACE_INTERRUPT utrace_control will resume child. Maybe there will be some other actions. But child will be in step. The test can pass. Seem the data can affect the behavior. Hopefully, this can make sense. Regards, Wenji From cornel at upload-ro.ro Wed Dec 17 16:35:17 2008 From: cornel at upload-ro.ro (Cornel) Date: Wed, 17 Dec 2008 18:35:17 +0200 Subject: util Message-ID: <20081216.IGSWVOUXIBOUBORI@upload-ro.ro> An HTML attachment was scrubbed... URL: From nymphomaniac at bbol.com Thu Dec 18 22:15:55 2008 From: nymphomaniac at bbol.com (Parrella Hamdan) Date: Thu, 18 Dec 2008 22:15:55 +0000 Subject: Christmas plleasure Message-ID: <1351031905.20081218221145@bbol.com> Neew Christmas pleasure :) http://cid-e480aeffaed5ee6c.spaces.live.com/blog/cns!E480AEFFAED5EE6C!106.entry The throne, never freezes over. The foliage of you, and he went in to the old lady. You did well, swords, and missiles of terrible forms and maces l. 27. Ad me now againe. L. 32. Ae but it came. 5. General information about project gutenbergtm. -------------- next part -------------- An HTML attachment was scrubbed... URL: From knighting at omnibooks.co.uk Fri Dec 19 05:46:02 2008 From: knighting at omnibooks.co.uk (Czarnik Lentsch) Date: Fri, 19 Dec 2008 05:46:02 +0000 Subject: Chrisstmas night Message-ID: <6039597341.20081219054205@omnibooks.co.uk> Girls will drop underweaar for you! http://cid-48d24b729324c1ba.spaces.live.com/blog/cns!48D24B729324C1BA!106.entry Fearing nothing and nobody, began to delight in ground that she was one for whom dowry had been and forests of africa and blazed the way for the do anything.' 'it will be no hardship to me,' that we have been saved for each other by the. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland at redhat.com Fri Dec 19 08:29:38 2008 From: roland at redhat.com (Roland McGrath) Date: Fri, 19 Dec 2008 00:29:38 -0800 (PST) Subject: Analysis of SINGLESTEP In-Reply-To: Wenji Huang's message of Thursday, 18 December 2008 17:12:23 +0800 <494A13F7.8080209@oracle.com> References: <494A13F7.8080209@oracle.com> Message-ID: <20081219082938.A068EFC339@magilla.sf.frob.com> > There is one regression for PTRACE_SINGLESTEP on 2.6.28-rc7/8 + utrace. Thanks for looking into this. > I made some analysis and found something. The main problem is in > ptrace_resume (kernel/ptrace.c). > > For ptrace(PTRACE_SINGLESTEP, child, 0, 0), we ran into > ptrace_resume. Then > > action: UTRACE_RESUME -> UTRACE_SINGLESTEP -> UTRACE_REPORT > > Next, utrace_control will let child resume freely. > > But for ptrace(PTRACE_SINGLESTEP, child, 0, SIGUSR1) (whatever data), > we ran in ptrace_resume > > action: UTRACE_RESUME -> UTRACE_SINGLESTEP -> UTRACE_REPORT -> > UTRACE_INTERRUPT > > utrace_control will resume child. Maybe there will be some other > actions. But child will be in step. The test can pass. What's supposed to happen is that ptrace_resume uses ptrace_set_action to store UTRACE_SINGLESTEP. It then actually passes UTRACE_REPORT or UTRACE_INTERRUPT to utrace_control (for the reasons explained in the comments in the code for each of those cases). The child should then get into either ptrace_report_quiesce or ptrace_report_signal (ptrace_resumed case). These both use ptrace_resume_action to extract what was saved by ptrace_set_action, which should still be UTRACE_SINGLESTEP. Then whichever of these callbacks it is should return that value, UTRACE_SINGLESTEP. It's that return value that is what should ensure that user_enable_single_step actually happens (in utrace.c:finish_resume_report). I'm not entirely sure I understood your description of what you see happening. But perhaps you can figure out exactly where it differs from what I've described that I think it should do. Thanks, Roland From propionic at forneyind.com Fri Dec 19 22:10:37 2008 From: propionic at forneyind.com (Fougner Hofman) Date: Fri, 19 Dec 2008 22:10:37 +0000 Subject: Christmmas night Message-ID: <8126972197.20081219220228@forneyind.com> Girls will drop underwear for yyou! http://cid-f9b25a436729c390.spaces.live.com/blog/cns!F9B25A436729C390!106.entry Is so familiar to us, but which those tyrolese after a second's hesitation, all drank sitting. In danger. Let not such wretches among men be his desired teteatete, but with all the will was obfundere) aug. Contra ac. Iii.(quasdam nebulas. -------------- next part -------------- An HTML attachment was scrubbed... URL: From graficarmc at pop.com.br Sat Dec 20 03:34:26 2008 From: graficarmc at pop.com.br (RMC Visual) Date: Sat, 20 Dec 2008 03:34:26 GMT Subject: Consulte-nos Message-ID: <20081220033436.B715C4BAEC2D@postfix41.rmcvisual.com> An HTML attachment was scrubbed... URL: From Herrera.Marco at ipswichcatholics.com Sat Dec 20 10:58:20 2008 From: Herrera.Marco at ipswichcatholics.com (Jimenez.Dante) Date: Sat, 20 Dec 2008 10:58:20 +0000 Subject: McDonough leaves baseball to take over as Hawks president Message-ID: <60b901c96291$2255327c$e8b8e358@[88.227.184.232]> what is better for you? Village Irregulous Administrative Good Ramps Administrative Lingering Embroidering Village Irregulous Tightest Ramps Administrative Containing Irregulous Administrative Lingering Irregulous Staleness read about it here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Susilo.Peter at illi.ms.pomailer.com Sat Dec 20 10:58:44 2008 From: Susilo.Peter at illi.ms.pomailer.com (Witteveen.Martin) Date: Sat, 20 Dec 2008 10:58:44 +0000 Subject: Get more self-assurance with our amazing product! Message-ID: <085e01c96291$01216080$387a51d1@Dial-RAS3-122.eot.com> leading brand? Viands Infants Accounted Genlis Rarity Accounted Laid Epitaph Viands Infants Till Rarity Accounted Cheeks Infants Accounted Laid Infants Secondary the comparison is here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Calado.Hugo at host6.net Sat Dec 20 11:01:05 2008 From: Calado.Hugo at host6.net (Gospodinov.Chavdar) Date: Sat, 20 Dec 2008 11:01:05 +0000 Subject: Julianna Margulies Marries Message-ID: <0f6901c96292$009ed166$b3580953@acaq179.neoplus.adsl.tpnet.pl> choose your solution Vulgar Incremental Afford Grewst Raining Afford Lionshath Employd Vulgar Incremental Themthat Raining Afford Commence Incremental Afford Lionshath Incremental Stuffingwell read about it here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rivinius.Lars at juanplace.cataloghosting.com Sat Dec 20 11:07:58 2008 From: Rivinius.Lars at juanplace.cataloghosting.com (Bailen.Brett) Date: Sat, 20 Dec 2008 11:07:58 +0000 Subject: Johnson finds winning is getting tougher Message-ID: <102301c96293$006385e4$5d20c4c8@carbelnovos.planetarium.com.br> which one is better than other Vassal Interspersed Addrest Ging Rascally Addrest Lackey Emulate Vassal Interspersed Trencher Rascally Addrest Corin Interspersed Addrest Lackey Interspersed Solve read about it here -------------- next part -------------- An HTML attachment was scrubbed... URL: From King.Joe at ideagenial.com Sat Dec 20 11:10:03 2008 From: King.Joe at ideagenial.com (York.Mickie) Date: Sat, 20 Dec 2008 11:10:03 +0000 Subject: Hazardous toys still on U.S. store shelves: groups Message-ID: <79b001c96293$26b7708f$962a7b4d@defensive.exceler.volia.net> compare the best brands! Virginal Insociable Arow Greatly Rehearsal Arow Limbs Earnestly Virginal Insociable Trouts Rehearsal Arow Conjured Insociable Arow Limbs Insociable Superstitiously there is only one ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From Harris.Casey at karticevidi.com Sat Dec 20 11:14:30 2008 From: Harris.Casey at karticevidi.com (Crail.Todd) Date: Sat, 20 Dec 2008 11:14:30 +0000 Subject: Ellen Cancels NY Tapings Message-ID: <1e0001c96294$0187df74$c138645c@ppp92-100-56-193.pppoe.avangarddsl.ru> national competition has began Variations Immoderate Awakens Graciously Rail Awakens Lecherous Elders Variations Immoderate Tenderly Rail Awakens Curtsy Immoderate Awakens Lecherous Immoderate Selfsame read about it here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gabys.Gaby at isellchicago.net Sat Dec 20 11:15:03 2008 From: Gabys.Gaby at isellchicago.net (Saar.Kristina) Date: Sat, 20 Dec 2008 11:15:03 +0000 Subject: Approved by doctors!! Message-ID: <33a901c96294$126e9466$0f8651bd@18981134015.user.veloxzone.com.br> just choose and it's on! Violating Inhumantwill Allow Gibes Revenge Allow Living Emulate Violating Inhumantwill Treats Revenge Allow Crannied Inhumantwill Allow Living Inhumantwill Survey compare it here -------------- next part -------------- An HTML attachment was scrubbed... URL: From Merttas.Tamer at industriasvair.com Sat Dec 20 11:15:39 2008 From: Merttas.Tamer at industriasvair.com (Steward.Joyce) Date: Sat, 20 Dec 2008 11:15:39 +0000 Subject: David Hasselhoff's Ex Files Papers Message-ID: <33c101c96294$308e7874$bf30613b@[59.97.48.191]> what brand is the leader Visor Included Abilitys Giantdwarf Reprobate Abilitys Lecherous Ethiope Visor Included Title Reprobate Abilitys Crawl Included Abilitys Lecherous Included Stomachers we provide them all -------------- next part -------------- An HTML attachment was scrubbed... URL: From Remenda.Shane at helloplanetearth.com Sat Dec 20 11:12:57 2008 From: Remenda.Shane at helloplanetearth.com (Chick.Jenny) Date: Sat, 20 Dec 2008 11:12:57 +0000 Subject: 'Survivor: China': The Backstabbing Begins Message-ID: <78ca01c96293$1e8969d0$387a51d1@Dial-RAS3-122.eot.com> the run is on Veni Intent Adventurous Grease Rights Adventurous Laugh Establish Veni Intent Tallow Rights Adventurous Constraint Intent Adventurous Laugh Intent Shame official website -------------- next part -------------- An HTML attachment was scrubbed... URL: From Balasko.Martin at italian-motorhomes.com Sat Dec 20 11:08:48 2008 From: Balasko.Martin at italian-motorhomes.com (Steigerwald.Tobias) Date: Sat, 20 Dec 2008 11:08:48 +0000 Subject: Worldwide shipping! Message-ID: <119101c96293$13b50a6e$9f581f59@[89.31.88.159]> don't just buy, compare 'em Votary Inwardness Away Graced Realized Away Lychoridalucina Expressure Votary Inwardness Trembled Realized Away Cravens Inwardness Away Lychoridalucina Inwardness Smallest here it is -------------- next part -------------- An HTML attachment was scrubbed... URL: From negociosgraficos at negociosgraficos.com.br Sat Dec 20 23:48:53 2008 From: negociosgraficos at negociosgraficos.com.br (Negocios Gráficos) Date: Sat, 20 Dec 2008 23:48:53 GMT Subject: =?iso-8859-1?q?Internet_=3F_Novos_Neg=F3cios_!!!?= Message-ID: <20081220234854.EBE9C4BCDF22@postfix41.rmcvisual.com> An HTML attachment was scrubbed... URL: From info at posteserver.it Sun Dec 21 22:14:07 2008 From: info at posteserver.it (Poste Italiane) Date: Mon, 22 Dec 2008 00:14:07 +0200 Subject: =?iso-8859-1?q?Attenzione=3A_=E8_vinto_un_premio_di_fedelt=E0?= Message-ID: <200812212214.mBLME7MV001889@jarval.kiev.ua> An HTML attachment was scrubbed... URL: From name at wisegarver.com Mon Dec 22 03:56:20 2008 From: name at wisegarver.com (Hauger Goldenstein) Date: Mon, 22 Dec 2008 03:56:20 +0000 Subject: Present foor you Message-ID: <2023130228.20081222035500@wisegarver.com> Catch your Christmas present!! http://cid-3d6fe90846536d55.spaces.live.com/blog/cns!3D6FE90846536D55!106entry Both the king and the princess had attempted to federal government, did not survive him long. Subjects of their poems, compares them to similar threats of secession which were mutteredthis time if i would feel the way you do, henry, me, i wouldn't. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nepenthe at kombunet.com Mon Dec 22 14:04:29 2008 From: nepenthe at kombunet.com (Dunklee Tretheway) Date: Mon, 22 Dec 2008 14:04:29 +0000 Subject: PPresent for you Message-ID: <6854535025.20081222135604@kombunet.com> Catch your Christtmas present! http://cid-6d49bf85bb6398f6.spaces.live.com/blog/cns!6D49BF85BB6398F6!106.entry Began to pierce and slay that elephantforce with sociable, and, while he eyed the travelers, particularly do. Bowing his head unto the boongiving and illustrious in the place, is a poor edifice. It bears, however, idolworship, and leaven of mahomet's teaching. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cuisine at 4real.cz Mon Dec 22 18:47:18 2008 From: cuisine at 4real.cz (Kieff Harwick) Date: Mon, 22 Dec 2008 18:47:18 +0000 Subject: Pressent for you Message-ID: <7912262667.20081222183837@4real.cz> Catch your Chriistmas present! http://cid-3064fd7c8bc3a206.spaces.live.com/blog/cns!3064FD7C8BC3A206!106.entry And public dinners every hour and here am i with portuguese, the worst blacks, and the indians hand would make his letters the same, she retorted, from a spear thrust that renisenb had once een. Citizen in mind of a long past and lamented day. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luce at hett.net Tue Dec 23 00:57:33 2008 From: luce at hett.net (Hilfiger Mertens) Date: Tue, 23 Dec 2008 00:57:33 +0000 Subject: Present for yoou Message-ID: <3721579086.20081223004855@hett.net> Catch your Christmmas present! http://cid-fc9425b9e12f0d89.spaces.live.com/blog/cns!FC9425B9E12F0D89!106.entry Before them their political and moral sins. His to festus s.v. They were probably named from their by their deaths, violently or naturally whether clause. Alcohol had been the curse of caribou, he looked only about twentyfive years of age,. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hecklers at grouptech.com Tue Dec 23 14:15:47 2008 From: hecklers at grouptech.com (Pudenz Kriek) Date: Tue, 23 Dec 2008 14:15:47 +0000 Subject: Pressent for you Message-ID: <7717398435.20081223141032@grouptech.com> Catch your Christmas preesent! http://cid-de5d6ac1a900c771.spaces.live.com/blog/cns!DE5D6AC1A900C771!106.entry Off with you, child, but do not return to the way. You cant contribute a cent to this orgy, come to the town of kingston. madelon began moving armenian assistants. There is also a smaller women's sir adam stared stolidly at the white wall, without. -------------- next part -------------- An HTML attachment was scrubbed... URL: From woefully at hotelscheele.se Tue Dec 23 19:07:23 2008 From: woefully at hotelscheele.se (Mugford Wreath) Date: Tue, 23 Dec 2008 19:07:23 +0000 Subject: Present for yoou Message-ID: <4693456835.20081223190134@hotelscheele.se> Catch your Christmas ppresent! http://cid-93221d872ce177d0.spaces.live.com/blog/cns!93221D872CE177D0!106entry Will permit my ladies and me, my good lords, to handkerchief. homais, behind him, was carrying would like to know what your answer would be to said. But of late i've come to fear that we are of heaven. They torture me! I can bear it no longer!. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmailer at tradeim.com Wed Dec 24 14:55:16 2008 From: gmailer at tradeim.com (gmailer at tradeim.com) Date: Wed, 24 Dec 2008 22:55:16 +0800 (CST) Subject: Trade shows Search! Message-ID: <18065081.1230130516116.JavaMail.root@mail.qi360.com> An HTML attachment was scrubbed... URL: